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ABSTRACT 


An evaluation is presented in this volume which, £or the purpose 
of this study, is defined as the adequacy of syatem design with known,, 
functional and performance requirements. The proposed Rockwell 
International AIDS III card, document and data flow are presented to 
^luanarise ^he concepts involved and the relationships between 
Ijunctions. The analysis and evaluation includes a study of system 
cbsq>atibility, processing rates, search requirements, and response 
accuracy as well as a consideration of operational components and 
hardware integration. Operational availability of the system <i.e. , 
the probability that the equipment will be able to perform the 
function when required) will not be confirsmd until specific hardware 
is identified and empirical data can be obtained. Results of the 
study indicate that the AIDS III System concept is operationally 
feasible if production capacity is slightly enhanced, but that 
operational complexity, hardware intergration, and a lack of 
conceptual data pertinent to some of the functions are areas of 
concern. For a synopsis of this entire report, see the Executive 
Siaamary in the Compendium (Volume I). 
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SECTION I 


INTRODUOTION 


Operational feafibility la at adequacy of ayatem 

daaigny proceaa control proeedureai and ayatem parlonaance when 
coaiparad with known functional and perforiMt'Ac#! requirementa, Thia 
definition ia uaed to diatinguiah between operational and technical 
feaaibility, which detenaines whether the eiciatencey atatuai and 
development riaka of the technologiea eaiployed tti the ayaten lead to a 
technically feaaible approach. 

Syateai deaign and perforauince can be yr.naidered aa either a 
technical or an operational iaaue. For the purpoaea of thia evalua** 
tion. ayateia deB|gn ia conaidered an operational iaaue. Syatem 
perforaiance inctudea iaauea of accuracy and conpleteneaat of aearchea 
and reaponaea. aa well aa ayatem availability and proceaaing ratca. 


Proceaa control includea the monitoring of ayatem performance * 
queuea and work flowa» to effectively enaure that proceaaing rate 
requirementa are achieved. 


A. SCOPE /OB JECTIVI^) 

The objective of thia AtbS 111 Subtaak waa to evaluate the 
operational feaaibility of the AIDS III Syatem Concept developed by 
Rockwell International. 

The January 1980 iaaue of the Rockwell AIDS III Syatem Concept 
document (Ref. !)» the Rockwell April ■* May 1980 reaponae to the data 
dictionary (which augawnted the January 1980 report), and the docu- 
menta referenced were uaed aa the baaia for evaluation. Supplemental 
briefinga received before May 1980 were alao uaed. No additiona or 
change a to the January 1980 Byatem concept except for thoae in the 
April - May 1980 addendum are reflected in the evaluation. 


B. ESSENTIAL ELEMENTS OF THE ANALYSIS 

To decide whether or not the AlDS»III Syatem ia operationally 
feaaible, four baaic queationa were aaked: 

(1) Nhat are the ayatem* a functional requirementa? 

(2) What are the ayatem 'a performance requirementa? 

(3) Doea the ayatem concept meet theae requirementa? 
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(4) Do Che dtfigncted herdvare and •ofCware meet cheae re*> 
quiromenta in Cerma of evailabiltCy» compatibility ^nd 
adequacy? 

Recogniaing the vai'ying levela of the AIDS III ayatem 
development I and the depth to which aome areai of the ayatem have been 
explored; not all queationa could be anawered with the aame degree of 
eompletens^aa « 


SECTION It 


SUMMARY 


Hhilf fch«cf »rm eonetrni ir«gardin| final dtiign and impl«Mneafcion 
Che indiciCiona era Chat Che AIDS 111 SyeCen conccpC ia opcraCionally 
feaeihlt if produccion capaeiCy ia alighcly ineceaaedi The operational 
coaiplexicy; Che iCaCua of work aCation developBenCf the hardware 
inCegration of critical funcciona) and a lack of conceptual aupporc 
data are the priMry areaa of concern* 

Siiaulation laodeling of the fingerprint card flow indicated that^ 
with the addition of a total of five work atationa in four functional 
the ayateii will handle 95X of the 1993 work load in leaa than 3 houra 
(99*9% within 4 houra). Further analyaia indicacea> hcwever, that the 
ayaten ia aenaitive to volune aurgea» and functiona within the ayatem 
have a low tolerance for equipaent failure. A aeven percent increaae 
in the work load will aaturate the ayaten at three pointa* With aingle 
unit failurea> nany of the functiona could not handle the projected 
work load. Since nany functiona are operating with limited apare 
capacity, additional atationa or overtiae will he required to work off 
hackloga created by equipaent failure or increaaea in voluae. The 
potential fila proceaaing backloga related to uneven workflow aan 
identified hy Rockwell auet be reaolvedi aince thia ccaaponent ia\'^n the 
critical path in the identification proceaa. • 

The high volume of data (66,000 aeaaages with 5.1 million byti^a 
of data per hour) and interdependency of the computer aubayatena cre.:^|:e 
a complex data network with a aingle point of control (the Syatem 
Superviaor). All of the aubayateaa exhibit aome degree of 
interdependency. If there ia a failure or degradation of one 
aubayatenii moat of the others will be affected. When the Syatem 
Superviaor ia down or degraded, all functions in AIDS III will be 
degraded or ceaae functioning. A properly aired configuration using 
available computer and atorage technology will aupport AIDS III, but 
aoftware and hardware configurationa still require additional 
development to ensure that cost-effective and workable computer 
subsystems are selected. 

Since the final computer hardware configuration has not been 
selected, it was impractical to do a dynamic simulation of the computer 
subsystems. As an elternative, a auBBMrixation and analysis of the 
operational eomponent/computer aubsyatem data transfer rates was scde 
in order to scope the computer configuration requirements. Baaed' on 
the availible data, off-the-shelf technology would support the AIDS III 
System. 

Development of a full set of performance requirements as w/Jll as 
a model of the computer data flow is reconnended to aaaiat in determin- 
ing the most effective hardware and aoftware configuration. In 
addition, since the drta base structure and its management is an 
integral part of the AIDS III and the development and maintenance coats 
to support the informaciron processes are significant, it is recommended 
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that a aaka/buy evaluation of a coviercially available general-purpoae 
Data Baae Management System (DIAMS) be made. 

Analysis of the search performance of the Automated Technical 
Search Pilot System indicates that it performs better (provides a 
lower miss rate of 5Z vs 24Z) than the manual technical search 
system. The search perforsMince of the AIDS II Automated Hame Search f 
compared with the manual system^ also indicates that a lower miss rate 
will be achieved. 

The processing of documents was not adequately covered. There 
were omissions of key processing functions^ location of work stations 
was not discussed) and the number of documents to be returned to the 
manual system Varied freatly from present procedures without 
explanation. This area was notable for its inconsistency and lack of 
complete concept development. 

An analysis of the AIDS III System Showed that by not microfilming 
the ''rush" requests and walking them through the system^ these requests 
could be processed within 30 minutes^ thus meeting this requirement. 

There is a high degree of operational complexity involved in the 
Semi-Automatic Fingerprint Reader, fingerprint classification, image 

3 arisen, and search review functions. These functions require a 
entrated effort, demanding accuracy, knowledge, 4ad reliability 
throughout the operational day. It is recommended that prototypes of 
the fingerprint classification, image comparison, and search review 
terminals be developed and tested prior to making a full commitment to 
these concepts. 

While the Minutiae Master File and Computerized Criminal Name 
File and Record Files will not generally require new data, they will 
require file restructuring and conversion when implementing AIDS) III. 

In Addition, a major, 15-month effort will be required to convert^ the f 
14.5 million fingerprint master cards to microfiche for use in th^ _ / 
automatic retrieval system. 

Additional development of facility requirements for the AIDS III 
System is necessary, as the latest AIDS III concept is not fully 
reflected in the current facilities plan. 

Table 2-1 summarizes the areas of study that were evaluated in 
the operational feasibility task of the AIDS III evaluation study. 
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Table 2-1 





AREA OF STUDY 


METHODOLOGY EMPLOYED 


FUNCTIONAL AND ANALYSIS OF ID GUIDELINES 
PERFORMANCE AND REUTED DOCUMENTS 
REQUIREMENTS 


COMPONENT CALCULATICWI BASED ON 

AVAILABILITY MTBFANDMTTR 


PRODUCTION 

CAPACITY 


STATIC ANALYSIS 

•CARD PROCESSING 
COMPONENTS 


« 


I 

u» 


•DOCUMENT PROCESS- 
ING COMPONENTS 


O O 

^ Q 
o z 


DYNAMIC ANALYSIS (GPSS) 

•CARD PROCESSING 
COMPONENTS 


SENSITIVITY ANAIYSIS 


TRANSPORTATION STATIC AND DYNAMIC 
BETWEEN WORK ANALYSIS 
STATION * 




Operational Feasibility Report SuBanary 


OBSERVATIONS 


IMPLICATIONS 


• THE RATIONALE FOR THE PERFORMANCE 
REQU I REMENTS AND CONSTRAl NTS 
HAS NOT BEEN ESTABLISHED. SEE 
SECTION V. 


FUNCTIONAL AND PERFORMANCE REQUIREMENTS 
COULD NOT BE USED PER SE AS OPERATIONAL 
FEASIBILITY CRITERIA. 


• ESTIMATED AVAILABILITIES ARE 
BETWEEN 0.988 AND 1.0. 


• MARGINAL WITHOUT SINGLE-UNIT 
FAILURES; UNSATI SFACTORY WITH 
SINGLE UNIT FAILURES. 

• CONCEPT 1SINCOMPLETL 

• UPDATES TO FILE NOT SPECIFIED 

• PORTION SPECIFIED IS ADEQUATE 


• MEETS ALL RESPONSE TIME REQUIRE- 
MENTS WITH FIVE WORK STATIONS 
ADDED TO FOUR FUNCTIONS. 

•SENSITIVE TO VOLUME SURGES AND 
AVAILABILITY OF WORK STATIONS. 

• SEE VOLUME IV, 

• INCORPORATED IN DYNAMIC ANALYSIS 


ATTHAT LEVEL, THE AVAILABILITIES DO NOT 
AFFECT STATIC OR DYNAMIC MODELED PROCESS- 
ING CAPACITY, 


MARGINALLY OPERATIONAL, RE-EVALUATE 
SYSTEM CONFIGURATION AND ARCHITECTURE 
TO ELIMINATE POTENTIAL PTIOBLEMS. 

UNKNOWN IMPACT ON THE Al DS 1 1 1 SYSTEM 


MARGINALLY OPERATIONAL IF SUBSYSTEM 
AVAILABILITY FALLS BELOW 95% (IN TWO CASES), 
THE SYSTEM WILL SATURATE AND THE BACKLOG 
WiaGROW. 






K> 
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TECHNICAL EVALUATION 



Table 2-1. Operational Feasibility Report Sununary (Cont*d) 


METHODOLOGY EMPLOYED 


ANALYSIS OF: 
•AIDS II RESULTS 


•AUTOMATIC TECHNICAL 
SEARCH PILOT SYSTEM 
RESULTS 


TECHNICAL EVALUATION 


TECHNICAL EVALUATION 


TECHNICAL EVALUATION 


• HARDWARE CONFIGURATION AND SOFTWARE 
PERFORMANCE REQUIREMENTS NOT FULLY 
SPECIFIED. 

• COMPUTER DATA 

TRANSFER RATES WERE NOT SPECIFIED. 
•A PROPERLY SIZED CONFIGURATION WITH 
OFF THE SHELF TECHNOLOGY WILL SUPPORT 
AIDS III. (SEE VOLUME II AND SECTION 
ll-B OF VOLUME III) 


• PERFORMS BETTER THAN THE MANU.5.L 
SYSTEM. 

• PERFORMS BEHER THAN THE MANUAL 
SYSTEM. 


•A SPECIAL^URPOSE DATA BASE MANAGE- 
MENT SYSTEM (DBMS) IS TO BE DEVaOPED 
FOR AIDS III. 

• THE HIGH RESOLUTIL^ DIGITAL IMAGES- 
GENERATED BY THE TECHNICAL FILE ' 
CONVERSION WERE NOT SAVED. 

• MINUTIAE MASTCRFIIE, THE COMPUTER- 
IZED CRIMINAL NAME AND RECORD FILES 
WILL REQUIRE RESTRUCTURING AND 
REFORMATTING FOR AIDS III. 

• SPACE REQUIREMENTS NOT CONSISTENT 
BETWEEN JANUARY 1980 AND MAY 1980 
SYSTEM DESCRIPTIONS. 

• SAFETY AND FIRE PROTECTION 
REQUIREMENTS INCOMPLETE- 


FUNCTIONAL AND PERFMMMilCE REQUIREMENTS 
COULD NOT BE USED SE AS OFiRATIONAL 

FEASIBILITY CRITERIA (Sff VOLUME IX) 

JPL HAS ESTIMATED THESE RATES TO SCOPE 
THE SUBSYSTEMS {SEE APPENDIX C. VOLUME llil 


THIS APPROACH MAY NOT BE AS COST-EFFECTIVE 
AS A COMMERCIALLY AVAILABa GENERAL-PURPOSE 
DBMS AND A MAKE/ BUY ANALYSIS I S RECOMMENDED. 

REPHOTOGRAPHING OF THE MASTER FINGERPRINT 
Fia IS REQUIRED FOR AUTOMATIC IMAGE RETRIEVAL 

THIS IS A COMPUTER FILE TO COMPUTER Fia CON - 
VERSION AND SHOULD BE STRAIGHT FORWARD. 


ADDITIONAL INFORMATION IS REQUIRED FOR 
ANAIYSIS 


ADDITIONAL INFORMATION IS REQUIRED FOR 
ANALYSIS. 




SECTION III 


METHODOLOGY 


The methodology that was developed end utilized to evaluate AIDS 
Ill's opet'etional feasibility is refleoted in Figure 3-1 and described 
below. 

0 


A. DATA GATHERING 

First, the study team gathered system concept design 
documentation consisting of Rockwell reports, engineering memoranda 
and similer materials (all references are listed at the end of this 
volume). The data gathering pro^ce&s ‘ncluded technical discussions 
with the FBI and Rockwell AIDS i'll VK'^1ect personnel. Tours of the 
FBI Identification Division in Uaah.u'gton D.C. were *:lso a source of 
information. 

Specific operational and design data were gathered and 
documented for each operational component* of the AIDS III System 
Concept. This included the five subsystem computer configurations and 
System Supervisor. Whenever applicable, information in the following 
areas was collected for each component: 

(1) Descr,iption of the component. 

(2) Service rates. 

(3) Number of units proposed. 

(A) Availability. 

(5) Operability. 

(6) Component status. 

(7) Interfaces. 

(8) Search performance and/or accuracy. 

(9) File conversion. 

(10) Design and implementation approach. 

(11) Issues and concerns. 


*The term "operational component" refers to an operation or c.^ocessing 
step (manual, automatic, cosiputer-aided, or combination thereof) 
required to perform a specific function. 
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DATA SOURCES 


tOCICWEU OOCUMEHTS (SEE REFERENCE USD 
AIDS III SYSTEM CONCEPT 
• AIDS TECHNICAL MEMOS 

MISCELLANEOUS REPORTS AND DOCUMENTS 
Fll AIDS III DESIGN GUIDEUNES 
INTERVIEWS WITH FRI PERSONNEL 
INTERVIEWS WITH ROCKWELL DESIGN PERSONPIEL 
ORSERVATIONSOF SIMILAR TYPE FUNaiONS 


DATA REOUKED 


OTHER AIDS IH AaiVITIES 


CURRENT TECHNOLOGY EVALUATION SURTASK 
CURRENT SYCTEM EVALUATION SURTASK 
ECONOMIC Analysis SURTASK 
ENVIRONMENTAL EVALUATION SURTASK 
TOP-DOWN FUNaiONAL analysis 


COMPONENT R^TERFACES 
CUHIENT SYSTEM fXI'ERKNCE 
DATA Flow 
DATA TRANSFER RATES 
DOCUMENT Flow 
MAMTENAPKX DATA 
NUMRER OF UNITS 

OPERATIONAL COMPONEPIT DESCRIPTIONS 
POSSMLE RANGES IN 0RIMD4AL 
VS OVJl (APPUCANT) MIX 

POSSMIf RANGES OF FINGERPRINT 
CARD VOLUMES 

REQUIRED CAPAOTES 

SERVICE RAt7S (THROUGHPUT) 






c=C> 


ENVIRONMENTAL 
EVALUATION 
SUB TASK 



DATA 

DICTIONARY 




OratATIONAL 

FEASMtiTY 

»OIT 



fOK)MANC^1l&»lfS TO 
KONOMIC FEASttIUTY 


A 




ouTPun 


COMPOP4EP4T OPERATKMML FEASmUTY 
SYSTEM OPERATIONAL FEASNIUTY 
DESIGN AND IMPUMENTATION ISSUES 
COMPONENT AVAIIARILITY 
PRODUCTION CAPACITCr""^" 

• COMPONENT 

• COMPUTER SUISYSTEMS 

• SYSTEMS SUPERVISOR 
COMPUTER SOFTWARE ANALYSIS 

COPIFIGURATION AND ARCHITECTURE 
ASSESSMENT 

SEARCH PERFORMANCE 

• SURJECrSEARCH 

• TECHNICALSEARCH 
(AUTOMATED TECHNICAL 
SEARCH PHOT SYSTEM) 


Figure 3-1. Operational Feasibility Evaluation Methodology 







H«d data baen avaiUblat the next step would have been the 
developaent of functional and perforaance requirenenta at the aystem 
and aubayatea levela. Uaing theae requireaenta aa atandarda, the 
dcaign would then have had a baaia for coapdriaon in evaluating ita 
adequacy. The fact that the new ayatea iapcovea perforaance of a 
particular function in not neceaaarily a benefit unleaa the exiating 
ayatea faila to aeet the aaae requireaenta. Thia aubject ia diacuaaed 
further in Section V. 


B. STATIC AND DYNAMIC ANALYSIS 

The third aajor atep in eatabliahing operational feaaiblity of 
the AIDS III concept waa to perfora atatic and dynaaic analyaea of tbi 
ayatea to deteraine whether it waa aufficiently robuat to acconaodat^ 
both changea in work load voluae and changea in ita mixture (e.g.i tlie 
ratio of criainal va civil inquiriea). 

Baaed on the data collected, each operational coaponent waa 
atatiatical'ly analyxed for availability and aervice rate capabilitiea. 
Thia proceaa identified potential problem areaa in the fingerprint card 
ayatem flow. It alao highlighted thoae componenta that would fail to 
BMet their throughput requirementa aa a reault of a a ingle unit failure. 

0 ' 

The dynamic aimulation of the AIDS III ayatem under varying work 
toada eatabliahed a more thorough teat of ita operational feaaibility 
(the atatic analyaia being only a "quick look" technique). A computer 
baaed aimulation model waa developed uaing General-Purpose Syatema 
Simulation (GPSS) aoftware. Uaing thia high-level aimulation language 
on the Univac 1108 computer, the AIDS III Syatem waa modeled to 
evaluate the ayatem capacity and analyae the concep'ta of queueing and 
card flow. The flow of card imagea for automatic retrieval and 
verification waa alao aimulated. The lack of aufficient data 
prohibited the developamnt of a dynamic aimulation of the ayatem data 
"flow through the computer. 

The model waa deaigned in a parametric manner, allowing the 
variation of work load voluaie and criminal/civil card mix. Variations 
in component service rates and numbers of units was also aK>deled. The 
data gathering and analysis activity produced the primary data for the 
components within the laodel. System bottlenecks were identifiod and 
i;eaolved by increasing the number of service units. Once the baseline 
^del had been established, it was enhanced by JPL to meet the FBI 
Guidelines. 

Throughout the building, testing, and operation of the model, 
reviews were held to ensure that the model was valid and reflected the 
AIDS III System Concept. Detailed discussions of the simulation model 
can be found in Section VI, Paragraph B. 

The Environment Analysis (Volume VI of this report) provided work 
load volume ranges and various mixes of criminal and civil fingerprint 
cards for sensitivity testing. These work load volusms were entered 
into the model, and the resulting card throughput was evaluated. 


C. TEOHNXGAL ANALYSIS 

li 

Data tranafar raquirawnta for tha Syataa Supervisor and each 
eonputer iubsysteia tpare auamarised. Analysis of this inforaaition was 
used in an atteapt to evaluate the proposed hardware configuration. 
Because of the lack of specifies about the final hardware 
configtiration (and sow asdiiguity in the subayotea functions) the data 
processing requlreawnts of the AIDS III systea could only be analyzed 
at a conceptual level. 

In addition to analyzing each operational coaponent and computer 
subsystea and developing a siaulation aodel» general Areas such as 
data base aanagementf search perforaance» systea 7Jipleaentation» file 
conversion^ and systea work flow control v^re reviewed and evaluated. 


D. DATA DICTIONARY 

The original schedule called for the coapletion of the 
operational feasibility evaluation in Februaryt 1980. At that time, 
however^ the subtask realized that there was insufficient data to 
coapletely evaluate the AIDS III Systea Concept. The deficieqpy was 
most prevalent in the areas of process control queueing strat44y« 
computer configurat ions/capacities > data aanageaent/handling and 
systea aonitoring. The missing data was documented and transmitted to 
the FBI. through the Data Dictionary (•ee appendix to VoXuiBe I). The 
Data Dictionary indicated the unspecified or insufficiently specified 
datu eteisents requii^d to complete the AIDS III Operational 
Feasibility evaluation. It was prepared in matrix foraaty with the 
rows reflecting the/ data elesMmts required and the colwans identifying 
the data needed for each eleaent (i.e«, area of data deficiency, data 
required, il^a format, and the subtask requiring the data). The 
additional data received from Rockwell as a result of this effort, 
pips the data previously gathered, was combined and used as the- data 
base for the Operational Feasibility evaluation. 
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SECTION IV 

AIDS III SYSTEM CONCEPT DESCRIPTION 


The Rockwell AIDS III card, doiiuaent, and data flow are 
preaented in this aeetion. The Intent ia to summarize the concepts 
involved, to indicate the relationships between functions, and to 
provide the reader with a basic understanding of each concept. A 
diagraassatic view is shown in Figure 4-1. The nases and abbreviatfona 
used throughout this volume were derived from Rockwell's documenkAtion. 

Details of the Rockwell AIDS III System Concept are descriied in 
their January 1980 docuswnt (Ref. 1)» the technical awswrandum 
prepared by Rockwell in response to the JPL Data Dictionary (see 
appendix to Volume I) which augmented the January 1980 report, and 
related docunmnts. A list of these docuaients can be found in the 
Reference List at the end of this volume. 


A. FINGERPRINT CARD PROCESSING 

The fingerprint cards and other documents enter the AIDS III 
system from the FBI mailroom (MAIL) as shown in Figure 4-2. The 
mailroom operation consists of opening the mail and separating the 
fingerprint cards from other documents. Documents are forwarded for 
processing as described in Section B, Docusmnt Processing. The alien 
registration and personnel identification cards are accumulated 
throughout the day. At the end of the day they are counted, date 
stamped for statistical reporting purposes, and logged (DATE STP). 
They are then classified (CLASS-C) and routed to the civil file with 
no further interface with the autoisated system. The criminal and 
civil (applicant) cards are forwarded for coding with a process 
control nusi>er (PCN). If a criminal/civil priority scheise is needed, 
the cards are separated at this point. 

0 

Rush requests for fingerprint card searches enter the system at 
the process control number (PCN) function. Processing of these 
requests is described in Section C, Rush Request Processing. 


1. Process Control Number Application 

When criminal and civil fingerprint cards arrive at the PCN 
printers, a uniquer isachine-readable, dated and sequenced process , 
control number is printed on each card. The process control nusd>er is 
used as the prisuiry accounting index. It is used to maintain an audit 
trail for associating the data on the card with the propessing 
performed by the system coiaputers. 


0 
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Figure 4*2* Fingerprint Card/Document Flow (Cont*d) 




2. Mierofila 

Froa the PCN epplieetionf the eerde aove to the aierolila 
ceaeree (HFILM) for fiimerprint iaege eepture. All carde are filacd, 
although aoac aay not be uaed in the iaage soapariaon ayatea* The 
objective ia to convert earda into fila iaagea aa aoon aa poaaible in 
order to ainiaiae the iapaet of fila proeeaaing delay on reaponae 
tiae. Carda deaignated for tcaporary file update and for peraanent 
file update are alao aent to the aicrofila caatraa. 

Roll fila froa the caaeraa ia proceaaed (FLAB) and converted 
into ultraaicrofiehei Two eopiea of each fiche are generated foe each 
of the 19 iaage eoapariaon and 13 verification terainala. The 
aicrofiehe are diatributad (FLOAD) to the iaage eoapariaon 
identification and verification (ICl and ICV) terainala » 


3. Quality Check 

After the fingerprint carda are filaed (NFIUf)^ they arc routed 
for a quality cheek (QC) and a aeparation of thoae carda to be reaoved 
froa the AIDS III autoaated proeeaaing ayatea. Garda are reaoved froa 
autoauted proeeaaing wheni 

(1) Neeeaaary inforaation ia aiaaing - returned to contributor 

(2) Year of birth ia leaa than the Autoaated Subject Search 
cutoff year (1958) - aent to the aunual ayatea. 

(3) Card haa a non-AIDS FBI nuaber - aent to the aanual ayatea 

(4) Card haa only four fingera - aent to the aanual ayatea. 

Alao entering the QC function are carda returned froa the aanual 
ayatea which were originally received with a non-AIDS FBI nuaber> or 
were not identified (non-identa) in the aanual ayatea and are being 
reaubaitted for an autoaated aearch. Carda that do not continue in 
the autoaated proceaa are paaaed froa quality control (QC) to wand 
out* (WAHD) and reaoved froa the ayatea. Contributor data and atatua 
deaignation are recorded with a data entry keyboard which allowa the 
ayaf^a to retain contributor and work load atatiatica while aonitoring 
card atatua. 


4. Bnc^ing and Encode Check 

Moat of the carda are paaaed froa QC to the encoding function 
(ENC), vhere data input foraata are checked and criain*! arteat data 
are encoded. Alao entering the encoding function ar4 eWda for AIDS 
aubjecta that weret 1) identified in the aanual ^yetea and now being 


*The PCN ia read with an optical character reader (OCR) wand. 


r«turnffc( for fU« updato and raaponia lar^aratlon in tha autoaatad 
ayatta{ 2) nofc idantifiad in fcha Mnual nawi iaareh (Card Indax 
Saefcion) and now baing ratumad for autoaatad tachnieal aaarch» or 3) 
not idantifiad in tha aanual fingarprint aaarch and now being added to 
the autosatad tachnieal aaarch Minutiae Haater file. 

All carda laaving the aneoding function (EMC) are paaiad to 
encoding cheek (ENCK) for an indapandant varification of the encoded 
datat The carda are than aapa rated by type into aaparata proeaaaing 

otreaM, 


5* Data Entry, blocking Out and Claaaification 

Carda with an AIDS PBX nuad>ar Caither contributor-auppliad or 
through the aMnual identification procaaa) are routed directly to data 
entry (DENT-’A)» The raaaining carda nuat raceiva a fingarprint 
claaiification bafora tha autoaatad aubjact aaarch. Criaiinal carda 
ara aant to blocking out (BLO), whara a high'^laval, Hanry 
elaaaifieation ia parforwd. Tha BLO function alao flaga criainal 
printa which ara probably illegible, ao that arraat data ara not 
entered in tha data entry procaaa. 

At the claaaification function (CLASS-A), civil, regular 
■ilitary and Coa at Guard carda froia ENCK receive full HCIC fingarprint 
cliiiification. Civil carda racaiya full claaaification because Bx>st 
(90%) of the carda are not identified in aubjact aaarch and ultiaiately 
require full elaaaifieation prior to autoaMted technical aearch. 
Military and Coast Guard cards racaive full classification as required 
by tha civil file. At the tisw of full classification, tha data are 
entarad into the oyataa using special data entry terminala which 
cowplewent the classification function (finger block display layout 
sinilar to the fingerprint card, and single purpose keys representing 
finger claasification syaibols). The finger claaaification is also 
written on the card. 

At the data entry work station (DENT"’A), subject search 
paraiaeters and arrest data are entered into the system and held for 
verification. At the data entry verification function (VDENT-A) the 
data are checked, character-bycharacter. After the subject search 
parameters are verified, the aearch is initiated. While the search 
takes place, the arrest data are vei^ffied. The results of the 
computer subject search (i.e., whether a candidate haa been 
identified) are indicated on the CRT terminal Screen to inform the 
VDENT-A operator of proper routing of the card as follows: 

(1) Criminal cards with no candidates to classification 
(CLASS-B). 

(2) Civil cards with no candidates to classification check 

(CLCi5'f* 

(3) Cards with candidates to search review (SEAR). 

(4) Military with no candidates to the civil file. 
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Cri«in«l e«irdt that had eandidataa fto« aubjaet aaarch but wara not 
idantifiad and varifiad vhan ehaokad againat tha fingarprint card ava 
ratumad Iron SRAR for a tachnioal ■aareh and ara alao aant to tha 
eiaaBification function (CLAg8*B). 

Aftar olaaaifieationf all earda arc procaaaad in tha claaaifi** 
cation ehack function (CLCK) uaing tha acM type of tarainal uaad in 
claaaification* Tliia function varifiaa tha claaaification pravioualy 
■ada. In checking, tha atored claaaification ia recalled to a ORf 
diaplay uaing tha KN. If naoaaaary, changaa ara Mdc and lagibla 
earda ara routed to oontarlina aort (C80RT)* Thoaa earda datarainad 
to be illegible ara raaovad froa tha procaaa and cant to autoaatfd 
eorraapondanea (AUTOCOR) to be returned to tha contributora. 

Alao aant to CLCK are civil earda with no aubjaet aaarch 
eandidataa, and thoaa civil cards that had non-identification 
eandidataa froai aubjaet aaarch but wara not poaitivaly l<i'jhtifiad by 
fingerprint cheek. Thaae earda ware fully elaaaified (CLA8S-A) prior 
to aubjaet aaarch, and therefore bypaaa the claaaification procaca 
(CLA8S-B) of tha eriainal earda. The claaaification check of civil 
earda ia ainilar to, but laaa axtenaiva than, that for criwinal earda. 


6. Fingerprint Reading 

At CSORT, tha earda ara inapacted to datenaina tha approxiaata 
canter Unas. Tha prints say vary froai high to low in each of the 
fingerprint boxas and sowe portions suiy even be outside the boxes. 

Tha cards ara sorted into groups having tha saaw centerline, and ara 
routed in batches to tha AutosuiCic Fingerprint Reader Systesi (AFRS) 
for siinutiae extraction. Based on the fingerprint ainutiae data froa 
AFR8, together with the classification data and other descriptive 
inforaation previously entered into the syatea, the autoaated 
technical search is initiated. 

Thoae cards rejected by the AFR8 require coaputer-aided, aanual 
ainutiae encoding on the 8eai-Autoaatic Reader (8AR). The coa^uter 
saves all the AFR8 data on rejected cards so that only prints of the 
rejected fingers need to be aanually encoded. When the rejected 
conditions are corrected at the 8AR operation, autoaated technical 
search for the card can proceed. A very few cards aay have 
fingerprints that cannot be successfully reconstructed by the SAR 
terainal (designated as rejects to be returned to the contributor). 
Following the AFR8 and 8AR operations, the fingerprint earda are 
routed to the search review function (8EAR). 

0 - 

7 * laage Coapariaon 

The aicrofiehe fingerprint iaages for the autoaated technical 
and subject search candidates are available to the iaage coapariaon 
identification (ICI) and verification (ICV) functions. Here the 
identification process is perforaed using aicrofiehe iaages rather 
than actual fingerprint cards. Theae functions are under coaputer 
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control and are initiated when two conditions are satisfied* First, 
the fingerprint isiage of the inquiry search card in siicrof iche format 
is displayed on the image comparison terminal. Secondly, a candidate 
list from either, the automated subject or technical search function is 
available. All image comparison terminals receive a copy of all 
inquiry search images so that any terminal (each one of which has 
access to only a segment of the master fingerprint image file) can 
make" iiomparisons with file subjects in its particular segment. 

, When the above conditions are satisfied, search candidates are 
reviewed (ICI) to determine tentative candidates by either the 
autoBMted subject or technical :iiearch. This is accomplished by 
comparing current search fingerprint images (received on microfiche) 
with master file microfiche images. The retrieval of all images is 
under coisputer control. Tentative identifications are designated by 
the < ,>erator tja be review-sd by an image comparison verification 
operator (ICV). Searches with no tentative identifications are 
designated as such and bypass the verification step. Results of the 
image comparison are then available at search review (SEAR). 


S. Search Review 

Search review (SEAR) reviews all fingerprint cards except those 
previously removed because of poor quality or illegibility, and 
military cards with no subject search candidates. SEAR perforsm two 
functions: search process evaluation and card routing. As the cards 

arrive at SEAR, the PCN is entered into the system and the search 
re^aults are displayed on a CRT terminal. For process evaluation, SEAR 
provides the final measure of quality control: the final human ? 
acceptance of no identifications based on automated search results. 

Those searches that have been designated as identifications by 
image comparison (ICI/ICV) require no further decisions, and the 
search results (displayed on the console CRT) indicate the proper card 
routing. Some fingerprint cards are returhed to the contributors per 
their request, and the remainder are retained in original hard copy 
form. A few are .returned to the nuinual system for file update. 

Inquiry cards designated as subject search candidates but which 
were not positively identified by image comparison (ICI/ICV) are,, 
routed to the classification function (CLASS^B) for preparation for an 
autoisated technical search. Those cards with contributor-'supplied FBI 
numbers that were not identified require a subject search* This is 
initiated by SEAR without routing of the card because all necessary 
data have been entered. These cards are set aside awaiting search 
results and subsequently handled the same as cards with or without 
subject search candidates. 

Searches designated as automated technical search with no 
identifications undergo a process evaluation wherein the SEAR 
operator, having a display of search results and search conditions and 
a detailed understanding of the search process, decides if a second 
search should be performed uaing different eearch arguments or 
cha rac ter i 8 t ic 8 . 


If th« inquiry learch card is a new criminal addition to the 
file, an FBI nui^er is assigned to that card at SEAR. The new 
criminal cirds to be retained are routed back to image capture (MFILM) 
for temporary image file additions on a daily basis. Temporary file 
additions arc similar to current work, since each image comparison 
terminal receives duplicate copies. Permanent file additions occur 
when enough (approximately 2000) additions accumulate to fill a 
microfiche sheet for a single segment of the file. Following 
permanent microfiche image file additions, the cards are filed (some 
civil cards are routed tolthe civil file for retention). 


9. Response Generation 

The automated response generation (AUTORESP) and automated 
correspondence, (AUTOCOR) functions are the remaining functions in 
fingerprint search processing, ^’^ese functions are concerned with the 
accumulation and sending of data bo the contributor. 

Responses are run on high-speed line printers in batches to 
allow the grouping of responses to the same contributor for reduced 
postage costs. The printed responses are generated at AUTORESP and 
sent to AUTOCOR for assembly. The high-speed printers at AUTORESP 
also produce name index cards to update the CARD Index name file for 
AIDS subjecCs prior to 1961. 

AUTOCOR associates responses with those cards to be returned to 
the contributor and submits the envelopes to the inailroom for stamping 
and mailing. 


B. DOCUMENT PROCESSING 

The processing of documents (i.e., dispositions and miscellaneous 
requests) is reflected in Figure 4~2 (page 2). In the mailroom (MAIL) 
the documents are separated from the fingerprint cards and sent to 
have a process control number assigned (PCN APPL). Since docuoients 
are of various sizes, the process control number assigned (PCN) is 
applied with a simple sequential nuinber stamp either by hand or an 
electrically driven stamp triggered by document insertion. 

Following the PCN APPL function, the documents are routed to a 
quality control and sorting function (READ). At READ, the docuamnts 
are reviewed, checked for quality and annotated. The dispositions are 
separated and sent for encoding (ENCDOC). The various remaining forms 
and letters are read, and the required processing is determined before 
encoding. All documents are subjected to a quality control review to 
assure that information for data entry (DENT-B) is correct. A few 
requests are separated for processing in the manual system or returned 
to the sender because no action is required or possible. 

At th^e ENCDOC function, the search and disposition data to be 
used for updating of the automated files are prepared for data entry 
(DENT-B). The encoding is then verified (ENDOCK), prior to data 
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entry, and sent to VDEMT-B for data entry verification and initiation 
of a subject search. Identifications are determined based on the 
information available from the criminal history files. No fingerprint 
comparisons are attempted for these documents. Data entry is verified 
(VDENT-B) and the appropriate action is initiated. Further activities 
related to documents have not been specified at this time. The 
current system includes: 1) for identifications, files are updated 

with the appropriate data Or response outputs are initiated for record 
requests and 2) for no identifications, a response is initiated as 
appropriate. All documents are now sent to the manual system for 
disposition or returned to the sender. 


C. RUSH REQUEST PROCESSING 

Rush requests are those that are hand-carried through the system 
to obtain the shortest possible response time. Some rush requests 
require card searches, and some are merely requests for records when 
no fingerprints are available. 

Rush requests achieve the quickest response time when the card 
is hand carried to each function in the process. As t?'t'$ card is pre-^ 
sented tat each station, the operator is expected to finish the card 
currently in process and accept the rush request as tho next item of 
work. The entire process allows a rush request to be handled in an 
estimated 30 minutes, and should not disrupt the normal work load if 
rush request percent/, tge volumes are comparable to those currently 
experienced. 

Requests for records requiring immediate action or telephone 
query are handled at the on-line query function (QUERY) as shown in 
Figure 4-2. This function through an on-line data entry terminal has 
access to the criminal history files. A hard copy of the records can 
be obtained usi;ng on-line printers. 

II 


D. COMPUTER DATA PROCESSING 


All card routing and data flow are under the control of the 
System Supervisor, as are all data that flow between the various 
computer subsystems. The subsystems do not interface directly with 
each other but rather through the Systems Supervisor as reflflcted in 
Figure 4*’3. The key control data element is the process control 
number (FCN) which is assigned to each fingerprint card and document 
as it enters the system. The PCN is the audit and control identifier 
of a card throsigh its processing in AIDS III. After the PCN number 
has been assigned and is recorded by the System Supervisor (SS) in the 
Master Transaction Record (MTR) and Transaction Record (TR) files, the 
card is processed as described in Paragraph A above. At each function 
that interfaces with a computer, the PCN number is recorded and an 
indicator is placed in the MTR as to the last location of that card. 

During the capture of the fingerprint card image onymicrofilm 
(MFlUi), and subsequent development of that isiage (FLAB), the roll and 
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aicrofichA location of the image is fed to the system and stored in 
the TR file. Ihe data captured at the classification functions (CLASS 
At By and CLCK) are also stored in the TR. 

After the search parameters are entered and verified (DENT-A/B 
and VDENT-A/B)y they are passed through the Data Entry and Display 
(DEDS) subsystem to the System Supervisor which initiates, through the 
Subject Search and Response Generation (SSRG) subsystem, a subject 
search. The result of that subject search is passed back to the 
System Supervisor, and then to the data entry verification (VDENT-A or 
WBNT-B) operator to direct the operator in the proper routing of the 
ca^’rd/document. The search data and the arrest information that have 
been captured during the data input process are stored by the SSRG 
subsystem in the TR file awaiting dispositive response from search 
review (SEAR). Those fingerprint cards with no subject search 
candidates are routed to the Automatic Fingerprint Reader System 
(APRS) vdiere the fingerprints are read and the minutiae data are 
captured. The minutiae data are processed against the Minutiae Master 
File (MMF) in the Technical Search (TSS) subsystem. If a candidate is 
located during the technical search, thj.8 information is then passed 
back through the TSS and Systems Supervisor to the SSRG subsystem. 

The list of candidates that has been generated, as a result of 
either a subject search or a technical search is forwarded to the SSRG 
subsystem. Using the FBI number, the SSRG looks up the associated 
microfiche location and forwards these data to the Image Comparison 
(ICS) subsystem. In the ICS, the appropriate microfiche for^^-the 
search inquiry card and candidate fingerprint image are selected from 
the microfiche file. At the image comparison identification (ICI) 
function, the image of the search inquiry card is placed on one screen 
while the candidate card image, under computer control, is displayed 
on a second screen. If there is more than one candidate, and the 
first is a non'-ident, the system automatically presents the next 
candidate microfiche image to the ICI operator. The operator, upon 
making positive identification, notifies the system. The identifi- 
cation is then verified at the image comparison verification function 
(ICV). Once an identification or non-identification has been made, 
this information, is directed to the System Supervisor and placed in 
the MTR. 

I Once the fingerprint cards themselves have reached the search 
rev.^ew (SEAR) function, the operator checks the MTR file and reviews 
the search results. If a positive identification is made, the SEAR 
operator instructs the system to generate an appropriate response and 
update the related files. The process control number is cleared from 
the system. If an identification has not been made, the SEAR operator 
can initiate a second search based on modified search criteria or (if 
it is a criminal inquiry card) assign it an FBI number to establish it 
as a new master card in the basic fingerprint file. 

The Management Report Generation and System Simulation (MRGSS) 
Task is part of the System Supervisor. Different files (hardware 
status, PCNs^ Manpower, etc.) are assessed and information contained 


in these files is used to create Management Reports, This set of 
files will provide ^ mechanism for data collection^ report generation 
and system performance monitoring. 

A software simulator which models the system operation will be 
used for predicting worR load volusms at the various functions 
including variations in input volumes, unavailable components, or 
other dynamic portions of the system. This simulation is inclusive 
down to the component level (i.e., the effect of removing a single 
component can be evaluated). The simulator package will access many 
of the same files utilized for the management report. 


SECTION V 


FUNCTIONAL AND PERFORMANCE REQUIREMENTS 


[ 
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A* DEFINITIONS 

Four phrases used in this section may require definition. 

(1) Functional requirement. 

( 2 ) Performance requirement. 

(3) Top-down functional analysis. 

(4) Measure of effectiveness. 

u 

Functional requirements are the collective capabilities that a 
system and its subsystem must possess to tullfill the users' objec- 
tives, Fttnctional requirements are not design characteristics. They 
simply indicate to the designer the capabilities that must be 
available in the system. 


Performance requirements describe the level of quality with 
^ich each function must be accomplished. Consequently , performance 
requirements are generally quantifiable and can. as such, be measured. 

The determination of the functional requirements of a system can 
be accomplished in more than one way. An extremely effective method 
is top-down functional analysis (see Reference 21 for a TDFA of the 
FBI's Identification Division). This method starts at the highest 
level obiective and systematically identifies all functions needed to 
reach that goal. When the complete set of functions supporting the 
obiective has been identified, each of the functions is in turn sub- 
divided into subfunctions until the lowest useful level is reached. 


Measures of effectiveness (MOE) are the parameters used to gauge 
the state and performance of a system in achieving its goals," They 
are used as a source of performance requirements, since performance 
requirements are essential to measures of effectiveness. 


B. METHODOLOGY OF REQUIREMENTS DEVELOPMENT 

The development of functional requirements is illustrated in 
Figure 5-1. First, a TDFA is performed. This analysis divides 
objectives and functions of the Identification Division into 
increasingly more detailed sub functions until further breakdowns 
become so design-dependent as to be unusable. Functions that, are 
candidates for automation are identified. Those functions that^ were 
automated by AIDS I and II are marked in Reference 21, as well as 
those which are to be automated by AIDS III. 
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Figure 5-1. Functional Requirements Development 













A functional deaign is then created that requites subsystem 
identificationf Next, interfaces between subsystems are defined, as 
well as specific functions and major components such as data files. 

In parallel with these steps, MOE are developed. The MOE are 
then related to the functional system design by correlating them to 
the functions of the TDFA by subsystem. 

The next step requires the involvement of the FBI, since the 
designer cannot know the iisportance of search accuracy or response 
speed without consulting the operators and sponsors of the system. 

After determining system performance requirements, the engineers can 
assign functions to appropriate subsystems, leading to a complete set 
of system and subsystem functional requirements. These requirements 
can be connunicated to the builders with assurance that the system 
will accommodate the necessary functions, all interfaces will be 
properly designed, and the system will respond and perform as intended. 


C. EVALUATION OF ESTABLISHED REQUIREMENTS 

The FBI has stated system requirements in two documents: the 

Work Requirements Statement (Reference 31) and the Design Guidelines 
(Reference 23). Since each of the specific AIDS objectives in the 
Work Requirements Statement is repeated and often detailed further in 
the Deaign Guidelines, the latter document was used as a source. 
Footnotes indicated below and in Tables 5-1 through 5-5 refer to 
paragraphs in the Design Guidelines document (Reference 23). 

The guidelines were arranged in categories and each category was 
evaluated separately. The five categories selected were as follows. 


1. System Objectives 

System objectives were those statements indicating overall 
benefits that should be obtained through the automated system. They 
were too general .to apply to the measurement of operational feasibility 
against functional requirements. They are paraphrased for brevity in 
Table 5-1 and discussed in more detail in Volume 1. 

2. Design Guidelines « 

The guidelines determine the system designer's development 
strategies (see Table 5-2). Reference paragraphs numbers 2 through 12 
are specific to the AIDS III evaluation and will not apply to the 
evaluation of alternative systems. 

3 

These design guidelines strongly influence evaluation of the , 
system feasibility in terms of design approach. They are generally 
0 considered appropriate except for "3-byte minutiae storage and 
matching," which may unnecessarily constrain the system designers. 

O ■ 
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Table S-l. System Objectivea 


Reference Paragraph 


Syatem Objectivea 


Achieve cost savings 

Improve quality of service 

Minimize and schedule overtime in advance 

Hsrdware procurements not to be based upon 
suggested configuration during evaluation 
phase 


Table S-2t Design Guidelines 


Reference Paragraph 


Design Guidelines 


Nondisruptive impleiaentation 

Parallel running of automated and manual 
systems to allow for file conversion 

Semi-automatic classification system not 
to preclude future automatic system 

Msnual fingerprint card retrieval system 
acceptable 

3-byte minutiae storage and isatching 
System based upon available technology 


Modular design for work load variations 



3 * System Constreints 

System constraints ere extetnally imposed and thus dictate the 
system environment. They define the boundaries of a working area 
within which a technically, operationally and economically feasible 
solution must be found to establish system feasibility. Consequently, 
constraints are used with both functional and performance requirements 
(discussed below). Constraints are paraphrased for brevity in Table 
5-3. 


4. Functional and Performance Requirements 

The remaining tables ( 5-4 and 5 - 5 ) briefly paraphrase the 
functional and performance requirements identified in the Design 
Guidelines document. Tlie performance requirements refer to performance 
levels that must be met either by the system, a subsystem, or a 
specific Component. Since these performance requirements provide the 
quantitative basis for judging the operational feasibility of the AIDS 
ITI design concept, a discussion of each item follows: 

(O Reference Paragraph l«c. This statement refers to the 
fi degree of accuracy that must be achieved by the system. 

The allowable miss rate for false or wrong identifications 
is zero. This requirement will not change when 
alternatives are evaluated. There is, however, an 
allowable miss rate for "missed" identifications. For the 
AIDS III evaluation, the requirement is that the new 
system perform better than the existing manual system in 
making identifications. This performance base is 
established in JPL Document 5030-457, Volume V, Current 
System Evaluation. This level of accuracy may need 
quantifying on an absolute scale for the evaluation of 
alternatives. 

(2) Reference Paragraph 4. This statement defines the 
permanent storage requirement for the Subject Search, 
Technical Search, and Identification/Verification 
Subsystems. 

(3) Reference Paragraph 8. This statement defines the 
projected work load that must be handled by the 
Identification Division system. The volume is used to 
determine the temporary storage capacity for the Subject 
Search, Technical Search, and Identificiation/Verification 
Subsystems as well as the interface capacity requirement 
for the system and subsystems (see Appendix I for 
discussion of work load value discrepencies) . 

(4) Reference Paragraph 9. The performance requirements in 
the Identification Division guidelines sometimes seemed 
too stringent, particularly in the case of the 8-hour 
response time for 95iS of the fingerprint cards. This 
requirement did not appear to be based on a clearly 


Ttbl« 5*>3« System Conetreints 


Refeirence Paragraph System Constraints 


l-i 

^ — , „ 

Resuin within current Identification 
Division space allocation 


1-4 

Fingerprint card to remain unchanged 


5 

Workday to be 18 hr/day, 5 day a/ week for 
routine process ing| 24 hr/day, 7 days/ 
week to expedite processing 


6 

Staffing to be at a ratio of 2 to 1, day 
shift to night shift 


13 

No more than 5 AFRS 

Table 5-4 • Functional Requirements 

Re f e re nc e Pa rag raph 

Functional Requirements 

1-d 


Preserve or improve the integrity and 
security of data 

1-e 


Preserve existing legal and account- 
ability features 

i-g 


Subsystems to be tested separately before 
large-scale implementation 

l-k 

• 

Support the National Crime Information 
Center Computerised Criminal History 
program 

1-1 


Not to preclude latent fingerprint search 

1-1B 


Not to preclude alternative aiethods for 
data transmission between origin and 
Identification Division 
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Table 5*5 • PerforiMnce Requiceaenca Evaluation 


Reference 

Paragraph 

RequireiMnt 

HOE 

Area 

Remarka 

l-c 

Improve fingetp^int identi- 
fication accuracy 

Accuracy 

Requirement 
relative to 
current system 

A 

Automated Subject Search to 
handle 1A.5 million records! 
Automated Techfjiical Search 
(ATS) to handle 14-26 
million records 

Permanent 

storage 

capacity 

Adequately defined 

8 

Work load to be 1973 actuals 
plus 25X 

Temporary 

storage 

capacity 

Adequately defined 

9 

Response time routine/ 
expedite to be: 

0.95 probable for 8 hr/30 min 
0.99 probable for 48 hr/8 hrs 
0.999 probable for 96 hr 

Response 

time 

Adjust if neces- 
sary to satisfy 
other requiremencs 

11 

ATS; based on minutiae and 
equal to or better than M-41 
Matcher 

Accuracy 

Qualitative; applies 
only to AIDS III 
evaluation 

15 

ATS CPU requirements (8 sec/ 
search) 

Response 

time 

Based on capability 
of an obsolete class 
of computer 

15 

APRS cards read/hr (210) 

Response 

time 

Rate of 250 used. 

Based on JPL Study and 
projected 50X increase 
based on APRS modifi- 
cation proposed by 
Rockwell 

15 

APRS Availability (95X) 

Avail- 

ability 

98.82% based on JPL 
study 
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id«nfclfiable need. It hei been agreed belween JJ?L and fchi 
Identification Diviaion that the requirementa atated in 
the guide linea would remain until it waa ah own that no 
operationally feaaible aoiution exiated. For example » if 
the S-ihouti 5-reader (APRS) one and one-half ahlft con- 
atrainta excluded any feaaible aoiution^ then the 
Tdentification Diviaion would relax theae boundariea. A 
more aubatantial aoiution will be aought during the 
evaluation of alternative ayatema (aecond phaBe)> 
Conaequently^ theae numbera are to be uaed aa a aet of 
initial parametera with which to teat ayatem performance » 
and not as strict performance requirements to be met in 
determining operational feasibility of the design 
concept. 

(5) Reference Paragraph ll. This statement refers again to 
the level of accuracy necessary for AIDS III design 
concept operational feasibility. This requirement is 
sufficient for the AIDS III evaluation final report, but 
may require quantifying on an abaolute scale for the 
evaluation of alternatives. 

(6) Reference Paragraph 15. This item lists perforraance 
levels that have been projected for AIDS III components. 

(a) The CPU requirement for a technical search based 
upon an IBM 350/65 employs an obsolete class of 
computers . 

(b) The APRS throughput rate is discussed in Appendix F 
of this volume. 

(c) The APRS availability is discussed in Section VII. 
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SECTION VI 


OPERATIONAL CAPACITY 


■ y The FBI Identilicatlon Division AIDS III Guidef.^ines (Reference 28) 
state that the ability of the overall systein shall be sufficient to 
provide: 

(1) a 0.95 probability of processing each of the cards/ 
documents in the design work load within 8 work hours for 
the routine work load and 30 minutes for expedite requests} 

(2) a 0.99 probability of processing the design work load 

II within 48 work hours for routine workf and within 8 hours 

' for expedite requests; and 

(3) a 0.999 probability of processing the design work load 
within 96 work hours for routine work. 

The processing time is the time,; it takes a card or document to 
travel between the mail room input the beginning of the process and 
the mail room output at. the end of the process. 

To determine the feasibility of the AIDS III System Concept in 
meeting these guidelines, a dynamic simulation model of the system's 
card processing flow was developed on the UNIVAC 1108 computer using 
the General-Purpose Simulation System (GPSS). The results of the 
initial simulation, using service rates and the number of servers 
proposed in the AIDS III System Concept, indicated that the AIDS III 
system would not process the Guidelines volume of 29,177 fingerprint 
cards per day. However, with a total increase of five work stations 
in four functions, the following results were achieved: 

. 

(1) 9.5.0% of the cards were processed within 2.9 work hours. 

(2) 99.0% of the cards were processed within 3.0 work hours. 

(3) 99.9% of ?|>e cards were processed within 3.8 ,:ik hours. 

An analysis of the AIDS III system indicated that, by not 

microfilming each fingerprint card and walking it through the system, 

"rush” requests could be processed within 30 minutes. 

The simulation model was only developed for the card processing 
portion of AIDS III. The applic&tion of a static analysis to the 
document processing components indicated that the number of units 
proposed would handle the work load. However, all functions relating 
to the processing of documents were not addressed. In addition, the 
location Of the work stations was not described in the Rockwell 
documents^'’ and the number of documents to be retrieved for the manvial 
system varied greatly from presetft operations without 'explanation (see 
Appendix. !)''. 

A 
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since the final hardware configuration has not been selected, it 
was not practical to do a thorough static capacity analysis of the 
coaputer subsystems. As an alternative, a sumarization and analysis 
of the operational component /computer subsystem data transfer require** 
Bents were made. Based on the data available, it is felt that if the 
configuration proposed is properly sized (i.e., sufficient processing 
rates, memary and storage capacity) and utilizes currently available 
technology, it will support the AIDS III system. The development of 
an effective networking structure and the utilization of a responsive 
data base management system will be the keys to effectively using the 
hardware/software selected. 


A. OPERATIONAL COMPONENT AVAILABILITY 


The deVelopaient of operational component availability utilizing 
Mean-TiBm-Between-Pailure and Mean-Time-To- Re store data did not 
materially affect the throughput capability of the various functions 
(see Section VII). However, when the effect of a single unit failure 
on the capability of an operational component was analyzed, a signifi- 
cant number of functions showed negative or marginal ability to handle 
the projected work load on a stand alone basis. Those operatiof^al 
components reflecting a near zero or negative spare capacity are of 
particular concern and are suonarized in T^ble 6-1. A detailed chart 
on the availability of all operational compcnents can be found in 
Appendix B, Static Capability Evaluation of dpcirational Components. 



B. STATIC ANALYSIS 

The static analysis of operational components indicates that the 
operational components have marginal^ spare capacity when operating at 
100% of estimated throughput capacity. It is qunstionable whether the 
components have sufficient resilience to deal with short-term surges 
caused by increased card input volumes. 

When all units of a component are functioning, there is a very 
small capacity margin in the following card processing functions: 
automated correspondence (AUTOCOR), centerline sort (CSORT), quality 
control (QC) classification (CLASS A and B) and encoding related 
functions ENC and ENCK (see Table 6-1). The fifteen work cells 
pl’oposed will just handle the projected work volumes. 

The spare capacity of N-1 units indicates the impact of a single 
unit failure within a component. Under this condition, most functions 
will be performed below the capacity required to support the estimated 
volumes, while odier units will performi ^marginally (see Table 6-1). 
This marginal production capacity is of/ooncern in functions with a 
small number of units, .such as the Autc>batic Fingerprint Reader 
Systems (AFRS), image comparison and verification (ICI and ICV), 
Semi-Automatic Readers (SAR) and search review (SEAR). The SAR 
function is of specific concern. 



Table 6-1. Component Capability - 

Static Analysis 



Operational 

Components 


" 


Acronym 

Description 

Proposed 
Units (N) 

X Spare 
Capacity of 
N Units 

X Spare 
Capacity of 
N-l Units 

APRS 

Automated Fingerprint 
Readet System 

@ 165 CPH (JPL Measurement) 5 

@ 250 CPH (Proposed Enhancement) 5 

-20.1 

21.0 

-36.1 

-3.2 

AUTOCOR 

Automated Correspondence 

25 

3.7 

-0.4 

CLASS-A 

Classl£lcatlon-A 

8* 

6.7 

-6.7 

CLASS B 

Class l£lcatlon-B 

3* 

15.4 

-23,1 ’ 

CLCK 

Classification Check 

3* 

53,4 

2.2 

CSORT 

Centerline Sort 

12 

4.5 

-4.2 

DENT-A 

Data Entry A-Cards 

6* 

20.0 

0.0 

DENT-B 

Date Entry B- 
Documents 

42 

3.3 

0.8 

ENC 

Encode-Cards 

2* 

6.7 

-46.7 

ENDOC 

Encode-Documents 

17 

4.5 

-1.6 

FLAB 

Film Processing 

2 

104.7 

2.3 

ICI 

Image Comparison 
Identification 

19 

10.9 

5.1 

ICV 

Image Comparison 
Verification 

13 

15.7 

6.8 

MAIL 

Open Mail and Sort 

6 

11.3 

-7.3 

MFIUl 

Image Capture on 
Microfilm 

6 

18.5 

-1.2 

PCN 

Process Control Number 

2 

63.3 

-18.3 

PCN APPL 

Process Control Number- 
Documents 

1 

0.0 

-ioo.o 

QC 

Quality Control 

14 

2.9 

-4.5 


[( 
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Table 6-1. Component Capability Static Analysis (coat'd) 



f- — — 

Operational 

Components 




Acronym 

f] 

Description 

Proposed 
Units (N) 

X Spare 
Capacity of 
N Units 

X Spare 
Capacity of 
N-1 Units 

QUERY 

ON-Line Query 

1 

40.6 

-100.0 

READ 

Quality Control- 
Documents 

11 

2.3 

-7.0 

SAR 

Semi-Automatic Reader 

7- 

16.7 

0.0 

SEAR 

Search Review 

15 

14.1 

6.5 

VDENT-A 

Data Entry Verification- 
A-Cards 

6* 

20.0 

b.o 

VDENT-B 

Data Entry Verification- 
B-Documents 

42 

3.3 

0.8 

WAND 

Wand Out of System 

5 

55.0 

24.0 

— - 

Work Cell 

15 

0.0 

-6.5 

*Per work 
cell by 

cell (i.e., would reduce 
the percent noted) 

the capability of 

a single work 
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A very small increase of poor quality prints (e.g., 5 per hour) 
can overload the capability of this function. The estimate is that 3% 
of the cards entering the APRS will require processing through the 
SAR function. If this percentage increases to 5%, the SARs will not 
handle the increased load and will have a backlog of 16 cards per hour 
(the equivalent of 3.2 work stations). The number of rejected cards 
will depend on two primary conditions: 1) the quality of the cards 

received, and 2) the performance bf the AFRSs. 

In general, the analysis indicates that the system is sized with 
a narrow margin. When one unit fails and is not repaired or replaced, 
the system will not be able to handle the work load. Because of the 
marginal capability of many functions, work backlogs that develop 
during a failure cannot be expected to be alleviated immediately when 
the unit is replaced. This backlog may require overtime or additional 
equipment. 

The maintenance policy proposed by Rockwell assumes that suffi- 
cient space, terminals and parts will be available for replacement in 
the event of failure (See Section VII, Paragraph A.). This is 
particularly significant for those functions identified above as being 
marginal. In addition, the estimated one-hour response time for a 
trouble or failure report must be reduced in these marginal areas. If 
the system is to maintain its throughput goals and keep overtime to a 
minimum, these marginal areas must be given close attention. 


C. AIDS III SYSTEM DYNAMIC SIMULATION 


1. Description of Simulation Model Results 

When the AIDS III design was simulated using estimated 1993 
input and the number of work stations designated, utilizations of 1.0 
occurred at Quality Control (QC), Centerline Sort (CSORT), Semi- 
automatic Reader (SAR) and Automated Correspondence (AUTOCOR). When 
utilizations are 1.0, the system will never stabilize and queues will 
grow without limit. However, the overloads at the station mentioned 
above were small, and the addition of one work station to QC, CSORT, 
and SAR and two work stations to AUTOCOR v?as sufficient to reduce 
utilization to below .95. 

With added stations, the system was simulated successfully with 


the following throughput times: 
Fraction 

Upper Limit 

0.999 

3.8 hours 

0.990 

3.0 hours 


0.950 


2.9 hours 


Table 6-2 compares the number of stations in the Rockwell AIDS III 
deaif^n with the minimum number p£ work stations required to 
successfully stabilize a simulated run< 

The analysis also indicated that the system is sensitive to 
volume surges and has a low margin of spare capacity to handle 
equipment failures* As a result, either additional work stations or 
overtime will be/required to work off backlogs created by the 
degradation of an up-line function or an increase in volume. 


2. Simulation Model Queuing Concepts 

An item in a queuing system generally spends its time either 
receiving service or waiting in line to receive service. The total 
time spent in the system is the sum of all of the wait tiroes plus all 
of the service times (ignoring, for the moment, such factors as 
transportation times between stations or delays while sitting in an 
output hopper). Service times for AIDS III are well defined and are, 
in general, quite short. With the exception of the time required to 
process microfilm and the service time for the SAR work station (which 
only a sioall fraction of the prints enter), the sum of average service 
times through the AIDS III stations does not exceed 20 minutes. 

Virtually all of the functions of the AIDS III system are served 
by multi-server queues. One line feeds each function, and the 
transaction of the head of the line can be handled by any of a number 
of servers. The average wait time to receive service from a 
multi-server queue is given by the following formula*; 

average wait time ■ ^ x 

W l“r 

where M ■ the number of servers 

B ^ the probability that all M servers are busy 

ts ■ * the average service time 

„ _ .. input volume x ts 

P ” utxlizatron « — — 

M 


The average wait time (in units of service time) is shown in 
Table 6-3 for 5, 10, 15, and 20 servers at various levels of 
utilization. 

/ 

// 

... - // 


Assumptions: 


1. Poisson arrival pattern 

2. Exponential service times 

3. All servers equally loaded 

° 5. First-in, first-out dispatching 

6. Ho items leave the queue 


Table 6-2. Conparison of AIDS III Design and Minimal Number 
of Work Stations for Successful Simulation 




AIDS III 

Minimum 

Acronym 

Description 

Design 

Number_ 

APRS 

Automatic Fingerprint 
Reader System 

5 

5 

AUTOCOR 

Automated Correspondence 

22 

24 

CSORT 

Centerline Sort 

12 

13 

ICI 

Image Comparison 
Identification 

19 

19 

ICV 

Image Comparison i| 
Verification 

13 

13 

MFIIif 

Imege Capture Hicvo- 
film 

5 

5 

PCN 

Process Control Number 
App 1 i c at ion-C^ rd s 

2 

2 

QC 

Quality Control Check 

14 

15 

SAR 

Semi-Automatic Finger- 
print Reader 

7 

8 

SEAR 

Search Review 

15 

15 

WAND 

Wand Out of System 

5 

5 


Work Cell 

15 

15 


Table 6-3, Average Wait Time (in Units of Service Time) 


P 

NUMBER OF SERVERS 

5 

10 

15 

20 

.4 

.02 

. ^ 

— 

— 

.5 

.05 

.01 

— 

— 

.6 

.12 

.03 

.01 

— 

.7. 

.25 

.07 

.03 

.02 

.8 

.55 

.21 

.11 

.06 

.9 

.76 

,67 

.40 

,28 

" .95 

3.5 

1.7 

1.1 

,76 

.98 

i 

9.5 

4.6 

3.0 

2.3 
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Table 6-3 is used- as follows! given a work station with 15 
servers, a utilization of 0.9, and an average service time of twenty 
seconds, what is the average wait time to receive service? Table 6-3 
shows that the average wait time for 15 servers with utilization of 
0.9 is four-tenths of a service time or, in this case, 8 seconds 
(0,4 X 20 * 8), It is important to note that, even with only five 
servers (if average utilization is kept at or below 0.95), wait times 
will not exceed three-and-a-half times the average. As the number of 
servers increase (and utilization is held constant) the average wait 
time decreases. 

Most of the work stations in the AIDS III design have several 
servers and, in general, wait times can be expected to be a maximum of 
four times the average service time. Since the sum of average service 
times is generally less than 20 minutes, it would be reasonable to 
expect that total average wait plus service times would be somewhat 
under two hours. However, note that if average input exceeds the 
capacity of the servers, utilization will be l.O (the servers will 
always be busy). In this situation, the system will never stabilize; 
average queue length and average wait time for service will grow 
without limit. The rate at which they grow will depend on the extent 
to which input exceeds capacity. 

With several servers and utilization less than or equal to 0.95, 
wait times are reasonably short. With a utilization of 1.0, the 
average wait time approaches infinity. With several servers, perform- 
ance degrades from very good to unworkable within the narrow band of 
utilization from approximately 0.95 to 1,0*. Thus, a system 
designed to run at a high rate of utilization (given the assumptions 
stated earlier for the wait time equation) is sensitive to increases 
in input. Even a small temporary increase in input could result in an 
average utilization of l.O. If this occurred at any station, the 
system would be unstable and average queue lengths would start to grow 
indefinitely. If the system input were underestimated by a relatively 
small amount in the design stage, an inherently unstable system would 
be the result. The important concept is that the system tends to 
either work very well or not at all. If a given AIDS III work station 
is underdesigned, by three servers, then adding two servers will not 
really improve the system. It will slow the rate at which the queues 
build, but they will still grow indefinitely. Adding all three 
servers, however, will generally improve performance to well within 
AIDS guidelines. This fundamental understanding that AIDS III will 
either work well within these guidelines or not at all was 
instrumental in designing the simulation model. 


*In Table 6-3, with 5 servers, a change in utilization from 0.8 to 0.9 
results in a change in average wait time of from 0.55 to 0.76 service 
times - an increase of approximate! 38%. A change in utilization 
from 0.9 to 0.98 results in an average change of from 0.76 to 9.5 
service times - an increase of 1150%. 
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ORIGINAL PAGE IS 
OF POOR QUALITY 


3 , System Simulation Simplifying Assumptions 

The General Purpose Simulation Syistem (GPSS) uses traiiCaotions 
which are moved through the system according to the programmed 
conditions. The fingerprint cards represent transactions in this 
aimulation. A GPSS can only tolerate a limited number of active 
transactions at one time. As the number of transactions increases^ 
the cost and time required for simulation increase dramatically. 
Because of l^he large volume to be handled, it was quickly apparent 
that one transaction could not represent a single fingerprint card, 
but must represent a group of cards. This idea of batching introduced 
its own problems. If one transaction represents ten prints, service 
times must be multiplied by ten. This causes average wait times and 
average total times in the system to be multiplied by ten. Another 
problem aggravated by the batch size is system stability. When the 
simulation starts, the system is empty. The first several trans- 
actions move easily through che system, without queuing causing a bias 
in the statistics. To overcome this, the system is run until it is 
reasonably stable. Then the statistics are reset (all transactions 
are left in the system), and the simulation is run for an additional 
period of time. The larger the batch size, the longer the system has 
to be run to be confident that the system is stable. Thus, the 
savings achieved by allowing one transaction to represent several 
prints is at least partially offset by the need to simulate the system 
for longer periods of time in order to achieve stability. Runs with 
batch sizes of 1, 2, 5, 10, 25, 50, and 100 were attempted. The runs 
with batches of 1, 2, 5, and 10 took inordinately long, and 25 was 
selected as the smallest practical batch size. 

O 

In determining the number of days to run each simulation, the 
determining factor was the number of queues at each station. Ideally, 
the system should be run until average queue length stabilizes. For 
most runs, it was found that the queues appeared to be stable after 
approximately three days of simulatior:«. Statistics were then reset, 
and the system was simulated an additional three days in order to 
gather the desired statistics. 

To keep the simulation within reason, several aspects of AIDS 
had to be simplified. Rather than simulate microfilm processing, it 
was decided to merely delay entry of a transaction into the ICI work 
station until a standard processing time had elapsed. Rockwell AIDS 
Technical Memo 80-008J lists a total processing time for microfilm 
(1000 frames/reel) of 159.7 minutes. No transaction was permitted to 
enter the ICI station until it was held for at least 159.7 minutes. 

Transportation was another aspect of AIDS III that was simpli- 
fied. In most cases, output from the work station is placed on a belt 
moving at a rate of 100 feet /minute. In many instances, the distance 
to the next station is trivial (as in the work cells). It was found 
to be more practical to simply omit transportation time for simulation 
runs , 
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Each work shift waa simulated to have a productive period of 7.5 
hours. Since the second shift is staffed at only half the level of 
the first shift, this had to be reflected in the model. Thus, two-* 
thirds of the transactions arc generated during the first shift. 

Rather than reduce the number of servers during the second shift, it 
was simpler to double the service time. This achieved the same effect 
since it halved the output of the second shift. The work cells were 
treated differently, since they were represehted by individual blocks. 
During the evening shift, transactions were routed only to half of the 
work cell blocks (rounded higher when necessary). Transactions 
remaining in the other blocks ar the end of the first shift were 
allowed to complete processing through the cell. 

k certain fraction of input is sent to the manual system from 
the WAND station. A portion of these transactions returns to the AIDS 
TIT system. The time spent in the manual system is not included in 
the simulation, nor is it included in the throughput calculations for 
AIDS HI. It was not simulated because the time invoiced (days) was 
not defined and was totally out of scale with the rest of the AIDS 
ITT. functions (minutes). 

Treatment of the work cells required simplification. Initial 
attempts at accurately simulating the entire AIDS HI system with all 
stations were not feasible, because the GPSS model was incapable of 
simulating such a large number of transactions, One Work cell was 
modeled as a separate andel. This was successfully done, and provided 
useful statistics. The problem of how to insert a simplified version 
of the work cell into the AIDS HI model was addressed. This was 
complicated by what has been described as the "pipeline" effect, which 
can be illustrated with a few examples. 

Suppose there is a system in which there are three serial Work 
stations. Each work station has one server and the service time 
distribution is exponential, with a mean of 55 seconds." The input to 
the first work station follows a Poisson pattern with an average 
arrival rate of 60 per hour. This situation is illustrated in Figure 
6 - 1 . 
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Figure 6-1. Three Serial Work Stations 


To aimplify thia model, an attempt was made to represent it with 
a single block, To reflect the fact that a transaction goes through 
three processing steps, the service time was tripled, as in Figure 6-2 
A simple simulation of this model showed that the maximum input that 
could be handled (without utilization reaching 1.0 and an infinite 
queue buildup) was 21 per hour. Average throughput time was 2570 
seconds. Clearly this simplification cannot handle the appropriate 
volume of input, nor is the throughput accurately represented. 


1 SERVER 
MEAN SERVICE 
TIME * 165 SECONDS 


Figure 6-2. Triple Service Time 


The next attempt involved tripling the service time, 
tripling the number of servers, as shown in Figure 6-3. 


and also 



60/HR 


3 SERVERS 

. . O 

MEAN SERVICE 
TIME- 165 SECONDS 



Figure 6-3. Three Servers} Triple Service Time 
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In fchii fixplilieationi the benefit! of e suit l-eeirver queue are 
obtained and| although the input of aixty pec hour can be handled, the 
average wait tine and the average queue length are understated. A 
ainple sinulati<,>n of this nodel yielded an average total throughput 
tine of 618 secqlrids. 

It was finally decided to node! the first block only as in 
Figure 6-A. 


o. 


60/HR 


i SERVfR 
MEAN SERVICE 
TIME 55 SECONDS 


Figure 6~4. First Block Only Modeled. 


A ainple sinulstion of this nodel indicated a total average throughput 
tine of 411 seconds. While this dearly understates the average 
throughput tine, the average queue length in front of the block will 
be correet. In the case of the AlD$ III model, since the work cell 
was nodeled separately, throughput tines are Well known. By allowing 
the work cells in the AIDS III isodel to be represented by single 
blocks, the mechanics of card distribution and queueing within the 
work cell is accurately simulated. The understated throughput time 
can later be added as a constant. Table 6'*4 provides a comparison of 
the original three-stage system and the three attempts to simplify it. 


4. Work Cell Simulation 

When the attempt to simulate the entire AIDS III concept failed 
(due to inadequate capacity In GPSS), it was decided to simulate the 
work cell separately. Once the characteristics of the work cell were 
understood, it was possible to replace each work cell in the AIDS III 
isodel with a single block. This simplification permitted the AIDS III 
model to run successfully. 

A schematic diagram of one work cell is shown in Figure 6-5. 

The upper left-hand corner of each block gives the number of servers 
for the function. The upper right-hand corner gives the service time 
in seconds and the service time distribution (E*exponential) . At the 
extreme left is the average hourly input of 156 (one-fifteenth of the 
total hourly input to all work cells). The small numbers on the lines 
indicate the fractions of output from a given function when the output 
can follow laore than one path. 

The work cell inode 1 was simulated successfully for a period of 
twelve days. 
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Table 6-4. Comparison of Attempts to Simplify 3-Stage System 


NO. OF 

WORK 

STATIONS 

NO. SERVERS 
PER WORK 
STATION 

SERVICE 
TIME PER 
WORK 
■ STATION 

INPUT/ 

OUTPUT 

RATE 

AVERAGE 

TOTAL 

THROUGIHWT 

TIME 

REMARKS 

3 

1 

55 

SECONDS 

60/HR 

1521 

SECONDS 

1. ORIGINAL SYSTEM 

1 

1 

165 

SECONDS 

21/HR 

2570 

SECONDS 

1. MAXIMUM INPOT/OUTPUT GREATLY REDUCE© 

2. TOTAL AVERAGE THROUGHPUT TIME 
GREATLY INCREASED 

3. AVERAGE QUHJE LENGTH MUCH LONGER 

1 

3 

165 

SECONDS 

60/HR 

618 

SECONDS 

1. TOTAL AVERAGE THROUGHPUT TIME 
GREATLY REDUCED 

2. /MERAGE QUEUE LENGTH 1NCC»RECT 

1 

1 

55 

SECONDS 
-J 

60/HR 

411 

SECONDS 1 

1. TOTAL AVERAGE THRCXK5HPUT TMVE 
GREATLY INDUCED 

2- AVERAGE QUEUE LENGTH CORRECT 


















The average throughput times for prints going to civil files or 
image comparisons (KFP hold) was 15.8 minutes* The average throughput 
times for prints going to automated correspondence (AUTOCOR) or 
centerline sort (CSORT) was 21,5 minutes. 


5* Additions to Total Throughput Time 

In order to simplify the AIDS III model, the time spent in the 
PCN and CSORT output hoppers was omitted. In addition, the throughput 
time for the work cell is understated as described in the previous 
section. After adjusting for batch size, the distribution of 
throughput times for the AIDS III simulations showed two distinct 
groups: (1) those transcations which did not go through image 

comparison functions (ICI and ICV) and (2) those which did. The 
average time spent in the PCN output hopper is 10 minutes. The 
average time spent in the CSORT output hopper is 5 minutes, and the 
average throughput time for the work cell is 25 minutes. The sum of 
these three times (AO minutes) was added to the throughput times for 
all transactions which did not encounter a microfilm processing 
delay. Nothing was added to those transactions which encountered a 
processing delay, since that delay is greater than the others. 


D. COMPUTER SUBSYSTEMS 

As the final hardware configuration has not been identified and 
specific equipment not selected, it was not possible to do a thorough 
static capability analysis of the computer subsystems. As an alterna- 
tive, a review and analysis of the proposed computer subsystem data 
transfer requirements were made. It is reconmended that a simplified 
model of the system data flow be developed in order to assist in 
determining the most effective hardware configuration for the 
functio7{al requirements of AIDS III as presented. 

In order to scope the size and complexity of the AIDS III System 
in terms of data flow, it was? necessary to gather and summarize the 
message volumes and related record sizes that will be tranferred between 
operational components and the computer subsystems. 

The primary objective of this activity was notto develop a 
specific set of rates, but to analyze the size of the configuration 
and scope the ct'^aplexity of the data transfer involved. Changes in 
volumes, card mix or inquiry identification rates could significantly 
change these data. 

Although the computer subsystems are not yet in the design 
phase''^ it is felt that sufficient data were available to perform the 
analysis necessary to scope the operational feasiblity of subsystems. 

The data used for the analysis were primarily derived from Refer- 
ences 1, (S and 7, and is detailed in Appendix D, Specific operational 
component requirements are detailed in Appendix C. These requirements 
are discussed below and summarized in Table 6-5. 


6-15 


Table b-S. Estimated Computer Subsystem Data Transfer Requirements 


— ' — — - — 

Computer Subsystem 

Number of 
Messages/Hour 

Number of 
Bytes/Hour 

Data Entry and Display 

23,324 

1,529K 

Image Comparison 

7,277 

185K 

PCN and Image Capture 

6,144 

37K 

Subject Search and Response 
Generation 

21,594 

783K 

System Supervisor 

61,221 

2,055K 

Technical Search 

8,320 

2,614K 


The computer subsystem configuration proposed will, from a 
conceptual standpoint, support the AIDS III system. There are some 
concerns regarding the complexity of the configuration in network 
structure, message switching, and data transfer requirements. There 
also appears to be a proliferation of real-time computer system 
concepts and mainframe hardware. 


1. Data Entry and Display Subsystem 

There is nothing inherent in the Data Entry and Display 
Subsystem (DEDS) to preclude its operability, but the timing 
requirements and input/output volumes are potential problems. 

The Subsystem has 'the highest message transfer volume (23,324 
messages per hour) of any subsystem except the System Supervisor. 

While the proposed configuration of DEDS is such that the processing 
is distributed oyer 14 Front End Processors (FEPs), it does complicate 
System Supervisor activities in selectively- leuelving and responding 
to the same FEPs. This can be accomplished but, in order to be 
effective, a proven and reliable network architecture and interface 
software is required. To meet the 30-second response time proposed 
(from the VDENT operator release of search parameters to the subject 
search response), the system will be demanding but within current 
technology. , 

The guideline to use Four Phase Equipment now in place could he 
a constraint in taking advantage of current technology. Functional 
requirements of DEDS should be carefully developed to ensure that the 
current configuration meets the needs of the system. 
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2, Subject Search and Response Generation Subsystem 

The Subject Search and Response Generation Subsystein (SSRG) 
hardwate appears to be well within current technology. Although 
correlating the information contained in the numerous data base files 
associated with the subsystem is complex^ it is readily feasible with 
current data base management technology. 


3, Image Comparison Subsystem 

The Image Comparison Subystem (ICS) handles microfiche location 
data. This is not dissimilar to existing computer-driven systems now 
commercially in use. From both a hardware and software viewpoint, 
there should be no difficulty in identifying the file to be selected 
and in directing the equipment to locate and retrieve it. Discussion 
of the station terminal is found separately in Section VIII. 


4. Technical Search Subsystem 


The Technical Search Subsystem (TSS) contains a number of 
specialized pieces of hardware (SARs, SPMs , AFRSs), A large volume of 
minutiae data is also nandled internally in the subsystem. The opera- 
tion of the Automatic Technical Search Pilot System (AfSPS) indicates 
that the concept is feasible (see Section IX), However, the system is 
expected to run at 100% CPU utilization (Reference 1, page 6-70), 
which is well above the 50% CPU utilization guidelines (Reference 1, 
page 6-65), The absence of sufficient capacity to clean up a backlog 
is a potential problem. In addition, the TSS consists of more than a 
purely technical (fingerprint) search. Extensive candidate filtering 
is employed prior to minutiae matching. Although there appears to be 
nothing inherent in the concept of this subsystem to preclude its 
operability, the amount of CPU used, even with the pre-matcher candi- 
date selection algorithms, could produce a throughput problem. 

As in other computer subsystems, the Specific requirements of 
the function must be stated and utilized whi|n selecting both hardware 
and software. The AIDS III system should ndt be bound to either the 
hardware or software used in the ATSPS, It must take advantage of the 
advanced hardware and software techniques available at the time of 
implementation and not held to the level of equipment used in testing 
a concept. 

5. System Supervisor 

The System Supervisor is the most critical aspect of the entire 
AIDS III System. If it is not reliable or does not function properly, 
the entire identification process will not meet its requirements or 
will fail completely. Yet, of all the subsystem concepts described in 
AIDS III, the System Supervisor is the least defined. This gives the 
impression that a bottom-up approach was taken in developing the AIDS 
III computer subsystems. This approach usually results in a system 
that does not perform in an optimal manner. 
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There are inaufflcient; deaign data to state that the System 
Supervisor is not conceptually viable. It may, however^ end up with 
more limited capabilities than stated, or be extremely costly in terms 
of computer overhead as well as software development and maintenance* 

a. Data Transfer . The main function of the System Supervisor 
is that of data control and routing. Over 61,000 messages containing 
2.0 million bytes of data are to be processed by this subsystem each 
hour. Many decisions based on the data source and system status will 
have to be made in handling this volume level. Protocols, retrans- 
mission of data, header information, equipment status, diagnostics, 
etc. are additional items that will act to substantially increase the 
System Supervisor work load. Various files under the control of the 
System Supervisor (MTR, equipment status, queue size, management 
report files) will be updated continuously and will require 
significant CPU time. 

The overall baud rates of the lines between the subsystems and 
the System Supervisor appear to be sufficient but do not include the 
equipment status, diagnostics, etc. 

b. Feedback and Control . AIDS III proposes that each 
subsystem, computer, and component will have a monitoring device 
connected in some fashion. These devices range from very simple (an 
empty hopper indicator) to very complex (switchover to a backup unit). 

This segment of the AIDS III concept is not sufficiently 
developed at this time to allow a realistic evaluation. Whether the 
development and maintenance of the proposed feedback and control 
concepts will be cost-effective has not been shown. 


c. Monitor and Control . The system simulation package and 
management report generation are also at an early stage of development 
and are only discussed conceptually. Both of these subfunctions of 
the System Supervisor appear to be large enough to occupy a signifi- 
cant portion of the System Supervisor CPU resources. They may be run 
in the backup machines so as not to interfere with the primary CPU. 
Based on JPL's experience in system simulation, sensor and system 
diagnostic data gathering, and information system development, these 
proposed functions are not small or uncomplicated efforts. 

There is a need for monitoring to reflect card volume, card mix, 
service rate, available units, and other parameter changes. The level 
of complexity of the automated monitoring and control of work flow 
will be an object of analysis in the second phase of the JPL study. 

It appears that the devices used to distribute cards to the 
cells (allocators) are a potential single point failure that would 
seriously disrupt the functioning of the system. The documentation 
does not adequately address the impact of failures in this equipment* 
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d. Computer Architecture . Although the proposed computer 
architecture is viewed as being loosely coupled in terms of stored 
data, there is a high degree of interdependency between the subsystems 
and the System Supervisor* A high volume of data is transferred 
between subsystems on an hourly basis (see Appendix C). Concern for 
data and system independence appears to be paramount in the configur- 
ation reflected in Reference 6, Figure 6-1. 

Regardless of which subsystem is inoperative, the others can 
only process work in the queue. If the flow rate of cards through the 
system is close to the projected plan, all computer queues will be 
fairly small except for the PCN and Image Capture Subsystem (PICS). 

If the system works as conceived, the configuration in Reference 
6, Figure 6-1, may not be cost-effective. This approach shows backup 
front-end processors (FEP) and central processing units (CPUs) in a 
number of areas to minimize lost processing time in event of unit 
failure. This appears wasteful of CPU power, unless the second CPU 
normally handles part of the work load. Half of the pj cessing capa- 
bility should not be allowed to remain idle for any othijr purpose than 
to substitute in the event of a malfunction. If the total system is 
procured at the same time a commonality of CPU model and vendor can 
result, and a minimum of "spare'* mainframes can be installed to back 
up the entire AIDS equipment complex. Even if some CPUs are forced 
into a larger model, the resulting flexibility could lead to 
substantial economies and improvements in performance. 

A primary item missing in the system concept is a definitive set 
of design requirements for the computer subsystems. The AIDS III 
System, the hardware configuration development and the ■ultimate vendor 
selection would benefit if a set were developed. Ihese requirements 
would address what has to be done in terms of function, data volumes 
and reliability rather than how it is to be done. The present level 
of architectural detail is too limiting to encourage a free and open 
response from industry. A good set of system design requirements 
related to data capture, processing, and response must also be 
developed. The development of functional requirements for the AIDS 
III System would. permit uninhibited configurations and responses from 
industry. 

Much more work is required on the System Supervisor. Its 
design, implementation and relationship to the other subsystems will 
be a critical point in determining the success or failure of AIDS 
III. Given that a computer (of some reasonable size) can handle the 
projected work loads, the major problem will not be hardware 
performance, but rather its cost and the cost to develop the 
associated software and networking. Until specific functional and 
design requirements are developed, the efficiency, effectiveness and 
costs of the subsystem cannot be realistically stated. The System 
Supervisor will be a complicated system to develop and maintain, 
requiring an extremely competent design approach. 
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In developing a configuration to support AIDS III, it nay be 
very beneficial to build a Model of the data flow. This would not only 
aasist in developing of data transfer requirements but could also 
assist in the selection of a cost-effective hardware configuration. 

.'I 

e, Subsystem Interfaces and Protocol . The interdependency of 
the subsystems and System Supervisor, and the transfer requirements 
from the data source points, through one subsystem, to the System 
Supervisor, to another subaystem does not fully support the loosely 
coupled concept. The usefulness of the loosely coupled and distri- 
buted architecture is reduced in direct proportion to the 
interdependency of the subsystem for data gathered in other 
subsystems. Although physically separated, all of the subsysteiss are 
logically tied very tightly together. In the development of loosely 
coupled or distributed information/data processing systems, software 
and interface protocols sometimes are not given the attention 
required. Just as each of the machines must have hardware to connect 
to other machines, there also has to be software to support these 
interfaces. 

Data handling varies significantly depending on its source 
format, use, etc. Software will be required to handle data routing 
decisions once transfer by the hardware is complete. As the number of 
machines and interfaces increases, so does the software necessary to 
handle the data. The more machines (especially front-end processors) 
involved in transferring data from one operational component to the 
subsystem that needs the data, the toore these hardware and software 
handlers are involved. A large amount of system resources could be 
expended in just passing and checking this information from one 
computer to another. Since a large portion of the AIDS III system 
deals with transferring data from one computer system to another, this 
concept and its associated problems should be carefully evaluated. 

Any simplification and/or reduction in the number of computers needed 
in a particular path should be encouraged. So long as any portion of 
the network depends on the output of another, multicomputer Systems 
become more vulnerable to malfunctioning as they become more complex. 

All protocols, line interfaces, etc. that are used in AIDS III 
should be purchased, not developed in-house. Standard sets are 
readily available through suppliers. The ability to upgrade hardware 
and take advantage of new technologies is always desirable. Nonstand- 
ard interfacing can preclude cost-effective hardware and software 
upgrades. In-house development generally brings higher initial 
costs, maintenance costs, and time delays. Unless there is a 
demonstrated need to do otherwise, commercially available products 
should be used. There will generally be a reduction in system 
implementation lead time corresponding directly to the amount of 
off-the-shelf hardware /software that is purchased. 

f. Diagnostics . The use of vendor-supplied diagnostics to 
facilitate hardware/software repair should not be overlooked. The 
expense of implementing these is clearly dependent on the machines and 
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system software utilized. Some of these, particularly CPU to CPU 
signaling, have proven quite difficult to iinpletnent in some of the 
systems used to process telemetry data from JPL flight projects. 

The executing of on-line diagnostics seems to imply that the 
processing functions of the system need to shut down before running 
diagnostics. Periodic system checks should be designed so that 
potential faults can be identified without disturbing overall system 
function until necessary (such as replacing a failed piece of gear or 
reloading a computer). For nonstandard or special terminals, fault 
isolation methods should be an important element in their design. 

Some system of self-initiated diagnostic routines, standard checks and 
fault recovery is essential. Fully-automatic monitoring and corrective 
action can become complex and unreliable. Activities such as running 
diagnostics, isolating problems, and switching around failing units 
should probably remain under control of human operators. As proposed, 
the presence of on-site spare parts and experienced maintenance 
personnel are essential. 


SECTION VII 


AVAILABILITY 


The availability (i.e,, the probability that the equipment will 
be able to perforin ita function when required) of the operational 
components and related subsystems of AIDS HI directly reflects the 
ability of the system to meet its requirements. In the Technical 
Memo, "Major Component MTBF/MTTR Summary and Availability Design Goal" 
(Reference 24), Rockwell only discusses hardware and equijmient Mean- 
Time-Between-Failures and Mean-Time-to-Repair of major deliverable 
assemblies purchased from various equipment manufacturers. Opera- 
tional and software aspects of availability and related problems are 
not addressed. 

The Mean~Time-Between-Failures (MTBF) and Mean-Time~to-Repair 
values acquired by Rockwell are from many different sources. Some 
data was obtained from documented references, while other sources were 
identified as being informal correspondence between Rockwell and the 
equipment manufacturers. Data collected by Rockwell over the past few - 
years from other programs and predictions based on MIL-HDBK-217 were 
also used (Reference 24). It is not clear, however, which data are 
from which source. Data sources were provided only for the film 
viewers, the Automatic Fingerprint Reader System, and the Four Phase 
Data Entry equipment. 

The maintenance data for each operational component as reflected 
in Appendix A, Operational Component Summary, do not include related 
computer subsystems (including the System Supervisor) or transportation 
system availability. The rationale for this is discussed below. 

The component unit availability, ranging from 0.9737 to 0.9997, 
did not significantly affect the simulation model results for the 
overall system. However, when the effect of a single unit failure on 
the throughput capability of an operational component was computed, 
thetre were some significant areas of conceim (discussed in detail in 
Section VI). , 

It has been JPL's experience that figures provided by equipment 
vendors tend to be quite optimistic, and records of operation rarely 
support their original optimism. Therefore, the numbers in the system 
concept should be viewed skeptically and Considered on a "best case" 
basis until specific hardware has been identified and empirical data 
can be presented. 


A. MAINTENANCE POLICY 

The original maintenance data presented in Reference 24 did not 
reflect response time (i.e., time between failure identification and 
beginning of repair). Rockwell Id ter estimated response time to be 
l.O hour in all cases. It was assumed that the hardware maintenance 
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personnnel will be properly trained and on site (Reference 25). 
Rockwell's estimatea were derived from failure data in Reference 24, 
and on predicted failure rates of equiptoent used in the AIDS II 
system. The number of failures expected for a 90S! confidence level 
were then calculated. 

The hardware maintenance staffing considerations are based on 
the establishment of a qualified maintenance force consisting of: 

(1) 2 stockroom clerks. 

(2) 2 electronic technicians ~ repair failed boards. 

(3) 8 electronic technicians - system lev®! repair. 

(4) 3 electromechanical technicians - trensport system repair. 

-•'n 

This crew would maintain and repair highly sorihistlc-pted computer 
hardware systems, the conveyor belt transportation sl-stem and related 
elements. li 


B. OPERATIONAL COMPONENTS 

To determine whether the system was able to handle the required 
throughput, single unit component availability based on Reference 24 
data was computed for each operational component. This computed 
availability (detailed in Appendix A, Operational Component Summary) 
was introduced as a factor in determining the service rates in the 
dynamic simulation model. 

The results of JPL studies of the availability of the Automatic 
Fingerprint Reader Systems (APRS) and the process control number 
machines (PCN), while different from Rockwell's estimates, did not 
substantially affect the ability of the AIDS III System to perform the 
fingerprint identification process in a given period of time. In the 
case of the PCNs, Rockwell estimated 0.9906 availability while JPL's 
Study showed 0.9813. For the AFRSs, Rockwell estimated 0.9943 (exclu“ 
ding processors) while JPL's study revealed 0.9882 availability. 

Since the source was empirical, J PL data were used for the dynamic 
simulation model. The JPL studies are discussed in Appendix H, Study 
of APRS and PCN Availability. 

Introduction of an availability factor in both the static 
analysis and dynamic simulation model for operational components did 
not materially affect their ability to ineet system throughput require- 
ments. 


C. COMPUTER SUBSYSTEMS 

Computer subsystem availability could have a significant effect 
on the ability of the AIDS III to meet its performance requirements. 
While today's processors and data storage devices development have 
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greatXy improved computer reliability, subsystem reliability will vary 
significantly between vendors. The hardware configuration will also 
affect system tvailability. The more networking, electromechanical 
operations and single point failures, the greater the chance of system 
failure. In selecting the final vendor and hardware configuration, 
reliability should be a major consideration. Beyond the period of 
equipment infant mortality, the roliability of the computer subsystem 
proposed should have minimal effect on the availability of operational 
components. Furthermore, Rockwell has proposed that each computer 
subsystem include a spare processor, available for immediate replace- 
ment in case of prime system failure. 

A more thorough analysis of computer subsystem availability 
should be made when specific hardware is proposed. With present 
hardware reliability, there is no indication that availability rates 
will adversely affect the operational feasibility of AI0S III. 


D. OPERATIONAL AND SOFTWARE FAILURE 

In reviewing hardware availability, a lack of concern as to the 
impact of operational and software failures on the system must be 
noted. Based on JPL's experience with state of the art systems, 
availability of the overall system is more affected by vpexational and 
software failures than by hardware failure. These items are not 
sufficiently addressed in the AIDS III System Concept when discussing 
availability. 

Additional failure and maintenance data related to software and 
technician failure are required for a realistic picture of system 
availability. Experience at JPL has shown that random software and 
operational failures do occur after the start-up phase of any data 
system, and are an important factor in the availability and reliabil- 
ity of a system of this size. 


E. SENSITIVITY TO equipment AVAILABILITY 

The AIDS HI design is sensitive to equipment availability in 
three cases if the component availability falls below 93% (see Table 
7-1), This is a potential problem that can be solved by adding a 
processing margin where required. 
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Table 1 - 1 » AIDS 111 Sensibivity to Equipment Availability 



Availability 

Betiroated 

Wovk Station 

Deed for 

Minimum 


Simulation 

Availability* 

PCN 

0.9906 

0.6102 

MFIUI 

0.9996 

0.8152 

WAND 

0,9986 

0.6608 

WORK CELL 

1 .0000 

0.9356 

APRS 

0.9882 

0.8607 

SAR 

1.0000 

0.7874 

SEAR 

0.9997 

0.9136 

ICI 

0.9972 

0.9425 

ICV 

0.9972 

0.9058 

AUTOCOR 

1,0000 

0.9541 

*At the indicated 

aval 1 abi 1 ity ra te a , 

utilization would 

reach l.O. 
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SECTION vm 


COMPONENT OPERABILITT 


The object of this portion of the evaluation was to deterraine at 
the component level if the AIDS III concept is operationally foasible 
in three major areas: 1) fingerprint card processing* 2) document 

processing and 3) computer subsystems. In the course of the evalua’* 
tion, many questions arose concerning design details, specific opera- 
tional functions and data handling. Because of the complexity of this 
system and the scope of evaluation in both level of detail and re- 
sources, only the conceptual questions that impact the overall system 
operability have been included in this report. Many detail design 
questions arose and are discussed in Volume II. An assumption was 
made that these would be addressed and resolved at the appropriate 
time in the design phase since feasible solutions are known to exist. 


A. FINGERPRINT CARD PROCESSING 

There is no evidence to suggest that the individual operational 
components described in the AIDS III concept will not work as pro- 
posed. The areas of concern, arei 1) operational complexity, 2) the 
status of work station development and hardware integration of func- 
tions, and 3) the lack of conceptual data for some functions. These 
concerns are discussed in this Section. 


I, Automated Correspondence (AUTOCOR) 

There is a lack of definition of the operations and functions 
that take place in this subsystem. The available information is 
sketchy and appears to assume chat the functions now taking place in 
related activities in the cuirent system will continue under AIDS 
III. How this transition is to be accomplished is not clear. AIDS 
III has work flow and computer system interfaces significancly differ- 
ent from the current operation. Additional developiaent of the system 
concept for this function is needed. 


2. Automated Response Generation (AUTORESP) 

This function is insufficiently detailed by the concept documen- 
tation. It is described at a more general level than most other 
functions. The process of response generation appears to be taken for 
granted. Discussion of the procedure and software to be used in 
support of this function is insufficient, and must be developed 
further. ,, 


// 


3. Claiilficition h, B and Claaaiftcation Check (CLASS A| B and 

CLCK) 

The AIDS III document (Reference 1, page 6-19) recoinmendi a 
apecial terminal as the best data entry device for the olasslflcatlon 
(CLASS A and B) and classification check (CLCK) functions. The 
rationale for this decision Is stated in Reference 1. It is not clear 
that a special terminal is a cost-effective design for these func- 
tions. AIDS III procedures still require that the classification be 
written on the fingerprint card. Consequently, the operator is 
required to perform two steps in the automated system, where only one 
is required by the manual system. Also, the operator is rfSquired to 
have two unrelated skills t fingerprint classification and data 
entry. As suggested by Rockwell in Reference I, in-depth studies are 
strongly reconmiended prior to committing to this concept. 

An alternate approach might be to mark the card at the classifi- 
cation work sCatlon, then enter all classification data at the data 
entry station. Eliminating a special terminal would save development 
esipense, as well as the cost of the 224-plus terminals themselves. It 
would also reduce related computer subsystem hardware, storage and 
processing requirements. 

The fingerprint classification and classification check func- 
tions proposed by AIDS III support three individual tasks: 1) finger- 
print analysis and classification, 2) classification data entry, and 
3) classification data entry verification. There are areas, however, 
that impact the productivity and cost effectiveness of the function 
and the ability of the classifier to perform the job well. These 
areas include closure, compatibility, error detecting, learning, job 
variety and economics. 

As presently conceived, there are two alternatives proposed for 
handling the classification and classification data entry functions*^ 
The first is a one-position approach, where the classification techni- 
cian classifies each fingerprint and keys a classification into a data 
entry terminal. The second is a two-position approach separating the 
classification task from the data entry/verification task (which 
exists for other data entry requirements as well). 

The structure of the card flow in separating the classification 
functions into two separate modes in the system, and the location of 
the classification check function in relationship to data entry and 
verification, do not make the selection of either of these two alter- 
natives as clear-cut as might first appear. It is recommended that 
additional design and testing be performed before commitment to a 
special classification terminal is made. 

On the surface, the one-position approach seems to provide 
increased error detection by the data entry task. However, it may not 
be as cost-effective. It can also p'resent an obstacle to learning the 
job. No special advantage or disadvantage is seen for closure, job 
variety or job skill. However, the mixing of two dissimilar skills 
can be detrimental to productivity. 


Th« two-poiition •pproich m*y be Bore economlcel and eatier In 
the training area. There feem to be some advantagea when di acuta ing 
akill leveli and job variety. An apparent diaadvantage of thia 
approach ia in error detection. Thia can be taitigated by the claaal* 
ficatton verification work atationt which ia expected to uncover data 
errora aa well ae clasaification errora. 

Of tpeciflc concern in the atea of job variety ia whether or not 
the claaaification technician would welcome relief from the claaai* 
fying activity when entering data or whether thia would be aeen aa a 
burden. The capabilitiea for thia poaition muat be determined at the 
clasaification level and not at the data entry level. This alao meana 
that the technician would be required to learn to manipulate the 
terminal at a fairly rapid pace. 

fingerprint card flow through the ayatem for claeditication data 
entry (CLASS A and CLASS B) and classification check (CLCK) should be 
reevaluated to determine the feasibility of the special clasaification 
terminal. Some consideration might be given to eliminating terminals 
at the CLASS A function (having terminals only at the CLASS B and CLCK 
functions). 

If a decision to use a special classification terminal is made^ 
several aapecti of the propoied work station design are of concern. 

The recommended keyboard has some obvious problems. The physical 
layout is most appropriate for a hunt-and-peck operating stylet snd is 
not conducive to easy finger movement in a quick'-response t touch- 
typing style. There is no beckspace key for charactejf corrections. 

The number sequencing is inverted t compared to the uafial calculator or 
computer terminal keyboard. The "Enter” key is in an awkward posi- 
tion, and the "Clear Card" key is next to the "Card Coidplete" key. A 
small error in finger reach could cause sn entire card entry to be 
lost. The same concern applies to the "Clear Entry" key, which is 
next to the "Add Reference" key. 

A detailed discussion of these concerns can be found in Appendix 
E) Special Classification Terminal. 

A third solution, which is beyond the scope of this report but 
which will be eddressed in the final JPL report, is to automate 
classification by designing a system that does not require Henry 
classification at all. 


4. Centerline Sort (CSORT) 

The proximity of this function to the Automatic Fingerprint 
Reader System (APRS) function is a consideration, since it is proposed 
that the cards be carried to the APRS via a conveyor belt, where they 
are stacked awaiting manual withdrawal by the APRS operator. If, for 
safety or facility reasons, the AFRSs are located in a separate room 
Or location, the conveyor belt mode of transportation may be restric- 
ted (see Section XII, Facilities) . 
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5* Data Entry and Data Entry Verification-Carda (DENT-A and VDENT-A) 

The primary concern aa to operability of the data entry (DENT-A) 
and data entry verification (VDENT-A) functiona ia whether problems 
similar to those encountered in the development and implementation of 
AIDS II will apply to AIDS III. 

Initial attempts to interact with the host computer in AIDS II 
were not successful due to insufficient file size and the throughput 
limitations of the host computer. The inability of the AIDS II system 
to hold unprocessed data beyond a preset length of time created a 
problem in its implementation. It is recognized that the original 
AIDS II host computer was old, unreliable and employed only because of 
budget constraints. 

The AIDS III design is based on the functional requirements for 
AIDS It, and calls for a data entry/verify concept that is similar, 
but on a smaller scale (storing of search data only). Because of work 
backlogs resulting in file overflows, this methodology of saving the 
search data was abandoned. Search parameters are entered to make the 
subject search, but not verified. The same data is later reentered 
and verified when an identification has been made and the file will be 
updated. The inability of the data base file management system to 
respond to the overflow caused by the backlog in the existing AIDS II 
system, along with the slow response caused by an overloaded host 
computer, resulted in a decision to take additional data entry steps. 

A main concern of the evaluation team in the feasibility of the DENT-A 
and VDENT-A functions is not their specific operational capability, 
but rather the ability of the proposed syst<>.m to handle file overloads 
and work backlogs of this nature. Data bae;* file structures and 
hardware configurations must be flexible and expandable enough to meet 
these types of occurrences, (See Section X, for additional comments 
on data base management.) 

In a system of the scale of the current AIDS II, the impact of 
redundant data entry is not significant, compared to not being able to 
process stored data. Under the expected AIDS III workload, duplicate 
data being entered into the system would have a serious effect on 
processing time and costs. 

The ability of the Four Phase front end processors (FEP) to 
perform to the level proposed in the AIDS III Data Entry and Display 
Subsystem is also a conciai"ni Gurrently, between 20-29 terminals are 
connected to each Four Phase FEP. AIDS III proposes that 31 terminals 
will interface with each CPU. Assuming that the search parameters and 
arrest data volume per message remain consistent with those currently 
used, improvements in the software or additional hardware will be 
required to meet the proposed System specifications. 

Another concern in the operability of DENT-A and VDENT-A is the 
sequence of the data as it is entered from the card. Under some 
circumstances (multiple offenses), it ia necessary to turn the card 
over a number of times for the data. It is recommended that further 
analysis of this'potential problem be made and a redesign of the screen 


format be considered. The screen format should reflect the needs of 
the data entry operator rather than emphasize ease of data handling 
for the computer. 


6. Film Processing (FLAB) 

The effect of a backlog at the Film Processing function (FLAB), 
caused by simultaneous film delivery from the microfilm reader sta- 
tions (MFLM), is of concern to Rockwell. This is addressed in Refer- 
ence 1, pages 18 and 19. T.t is not clear how the figures on page 19 
were derived or what steps will be taken to avoid this problem, While 
it is stated that the possibility of a backlog is reduced by having 
two processors in the lab, the effects of one being down or of an 
uneven work flow should be addressed in more detail. This could 
present a significant bottleneck in the system, as the microfiche 
processing is on the critical path in the identification process. 

The handling of fingerprint cards requiring refilming due to 
processing problems is not addressed. This problem could develop into 
a complex control situation in locating and recycling the cards 
involved. The Master Transaction Record (MTR) will be the focal point 
for this control. Quality control requirements in the film processing 
laboratory were not fully addressed. The film processing activity 
must be constantly monitored with microscopes and densitometers. 


7r Image Comparison Identification and Verification (ICI and ICV) 

The Image Comparison Identification and Verification (ICI and 
ICV) functions have the same possible operational problems. While 
these stations have not yet been developed and are of a conceptual 
nature, it is reasonable to assume that they can be developed. What 
is of concern, however, is the criticality of the need for clarity in 
reading fingerprints. The use of ultrafiche at 2000 images/fiche 
requires tremendous magnification when reading '’ie image. Focus and 
ambients dust become significant operational problems. A visit to the 
Montrose, California, Directory Information Office of the Pacific 
Telephone Company demonstrated this problem. They are using MDS 
ultrafiche storage and retrieval systems (the same vendor and concept 
proposed for the FBI). In their system of 200 images/fiche, dust 
definitely presents a problem. AIDS III will have 2000 images/fiche. 
The JPL Photograph}^ Laboratpry has a similar problem with microfiche 
and finds it necessary use electrostatic air cleaners* Before a full 
commitment to this approach is made, a prototype should be developed 
and thoroughlv tested to prove the concept. 

In addition, special lighting arrangements will be required to 
reduce eye fatigue. Current operations of a similar nature, with less 
and critical comparison and reading requirements, are equipped with 
controlled lighting. This may require the construction of a separate 
work area. 
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Semi<-Automatic Reader (SAR) 


The prototype seems fairly awkward to operate, and the cursor 
positioning seems time-consuming. Over the workday, eye fatigue may 
become a problem and a special room with controlled lighting will 
probably be necessary to alleviate eyestrain. 

Using a trackball to position the cursor seems to limit the 
speed of this operation (and hence the a<j«uracy). Special handling 
and use of the SARs could become a limi^ ir«g\factor in the success of 
an automated technical search for some carus^ A very small increase 
in poor quality prints (e.g., 5 per hour) can easily overload the 
capability of the SARs. The basic assumption lhat only 3 % of the 
cards from the AFRS will be rejects may be optimistic or at best 
highly variable (see Section VI). 

Another approach would be to use a light pen and CRT capable of 
recording the X-Y coordinates designated by the operator. Each 
minutia is touched with the light pen and its X-Y coordinates are 
automatically recorded by the computer. The direction of the minutiae 
can also be entered with this efficient, human-engii^eered technique. 


9. Search Review (SEAR) 

The functions and decision processes required of the SEAR 
operator are rather complex. The function will require concentration, 
reliability, accuracy, and detailed knowledge of the entire system by 
the operator, in addition to a high eye/hand coordination in routing 
the card to one of seven future operations. In 15% of the cases, the 
SEAR operator must assign and verify an FBI number for new cards being 
added to the file. 

It will require quick response for an operator to sustain a rate 
of 150 cards/hour. The review of data on two CRT screens with differ- 
ent formats, along with various hand operations (data entry, handling 
the PCN wand reader, and card sorting) gives the impression of a 
highly sophisticated operation requiring a great degree of concentra- 
tion, ability and dexterity. 

The handling of cards whose print images have not yet been 
processed through the image comparison functions (ICI end ICV) is not 
addressed. At SEAR, there is a real potential for card handling and 
storage problems. 

The SEAR physical console is conceptual at this time, although 
Rockwell states that its design will utilize standard components. The 
implementation of such a console could be complex. A prototype of the 
dual screen SEAR console work station should be developed to thoroughly 
test the operational concepts proposed. In general, the SEAR function 
Still is only a concept and requires significant additional 
development. 
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10. Wand Out Of System (WAND) 


The use of a hand wand reader in addition to keyboard data entry 
appears to be an awkward combination. A significant loss of efficiency 
and accuracy may be caused by combining card handling, keyboard entry 
and wand manipulation. A stationary optical character reader and 
associated keyboard may permit greater productivity and accuracy in 
this function. 


B. DOCUMENT PROCESSING 

There are three major areas of concern regarding the AIDS III 
concept design for processing documents other than fingerprint cards. 
They are; 

(1) Omission of key functions. 

(2) Location of work stations not documented. 

(3) High number of documents returned to manual systems. 

With 14,500* documents a day to be processed, this portion Of the AIDS 
III system requires much more attention that it has received thus 
far. These areas of concern are discussed below. 


1, Omission of Key Functions 

The documentation stops at the point at which miscellaneous 
documents and dispositions are used to initiate a subject search 
(Reference 7, page 6). No functional blocks are described for later 
processing, particularly where an identification or a file update 
would be performed. The handling of dispositions and some miscella- 
neous documents requires both an identification and file update step. 

Final disposition reports (FDRs) are Sent to the FBI Identifica- 
tion Division as a result of the action of a court. In many cases, 
the offense that an individual is convicted of and sentenced under by 
the court is not the offense he was arrested for. This makes it 
difficult for the FBI to match the offense on the FDR to the offense 
in their records. Compounding this problem is the tendency for the 
date on the FDR not to match the date reported on the arrest record. 


*Reference 42, page 12, projects a daily processing volume of 22,000 
in 1993. This is in conflict with ID Division Guidelines , Reference 
23 page 3 and other Rockwell documents (i.e., Reference 7, pag* (i) 
which specify 14,500 documents per day. See Appendix I for other 
discrepancies. 


Under the current AIDS IX system, the FBI requests a "proof list" of 
offenses within a 30~day window of the date cited on the disposition 
to compensate for this situation. This proof list is printed out. In 
the case of an FDR with a contributor-quoted FBI number, one proof 
listing is printed. In cases where no FBI number is supplied, proof 
listings are printed for all candidates found as a result of a subject 
search. Both types of requests could be initiated from the data entry 
functions (DENT-B and VDENT-B). Up to this point, the AIDS III 
concept will accomnodate this process. 

Under the current AIDS II system, an identification process is 
run once the proof listings arrive at the appropriate work stations. 
The FBI must be sure that the person described in the FDR is the same 
person found in their file, with or without an FBI number. This 
identification process is analogous to the identification process used 
with fingerprint cards. However, in the case of FDRs, physical 
characteristics (e.g., color of hair, eyes, etc.) and other FBI 
acceptable data (e.g., date of birth. Social Security number, etc.) 
are used. Once the identification process has been completed, match- 
ing must be performed. In this procedure, the acquittal, conviction, 
and/or sentencing data on the FDR is matched with the arrest data on 
the AIDS II~generated proof list. After the offense and disposition 
data are matched, a file update transaction is coded, key entered and 
key verified. A similar series of steps is followed in response to 
correspondence requesting a correction to the FBI files. 

None of the steps described above (identification, matching, 
file update-date entry or file update-verify) are covered in the AIDS 
III concept. 


2. Location of Work Stations Not Documented 

In the Rockwell documentation, a great deal of discussion is 
directed toward the work cell and alternative methods of optimally 
allocating facilities for the processing of fingerprint cards (Refer- 
ences 1 and 8). Very little is said about the facilities for proces- 
sing documents. For example, in Reference 1, a floor plan is shown 
". . . which accommodates everything except the PCN machines and image 
capture machines ... the latter items are assumed to be located near 
the mail room, which is assumed to be on another floor" (Reference 1, 
page 119). In Reference 8, page 28, the PCN machines are shown to be 
located with the card processing work clusters. It is not clear in 
either document if these include pCN devices used to process docu- 
ments. It is doubtful that they are, yet it is not specifically 
documented one way or the other. 

The same problems are found with the locations of other document 
processing units. While the quality control check, read, annotate 
(READ) and encoding (ENCDOC) functions are said to be grouped together 
into cells, their locations cannot be found on any floor plan. At the 
same time, the location of encode checking function (ENDOCK), which 
should be located with READ and ENCDOC, is not discussed. 


3. Abnormal Number of Documents Returned to Manual System 

According to the design^ over 93% of the documents processed by 
AIDS III will be sent on to the manual system after the automated sub- 
ject search. If we were to include the omitted functions discussed in 
paragraph It we would have to expect that the design would still 
direct the vast majority of documents into the manual system. This is 
in direct variance with the current AIDS ll/manual system. 

Since dispositions make up 67% of the daily arrivals of docu- 
ments projected for AIDS III in 1993, they would make up the large 
majority of those going back into the manual system. Currently, the 
disposition notices are simply thrown away after being used as an 
update to an automated or manual record. We have no documentation to 
suggest that this policy is expected to change. Therefore, it remains 
unexplained as to why the bulk of these forms is to be sent into the 
manual system under AIDS HI. 


C. COMPUTER SUBSYSTEMS 

All of the subsystems have some degree of interdependency. If 
there is a failure or degradation of one subsystem, most of the other 
subsystems will be affected. Naturally, the further down-line the 
problem, the less the effects (other than the backing up of queues) 
are felt. 

There are two conditions that have an immediate effect on a 
subsystem throughput. The first occurs when the System Supervisor is 
down or in a degraded mode. All functions in AIDS III will be degraded 
or cease functioning altogether. 

The second condition occurs when a subsystem itself is in a de- 
graded mode or down. This has the effect of drastically slowing or 
stopping all work in a subsystem except the totally manual operations 
(Blocking Out, QC Check, etc.). The queues will build in direct 
proportion to the amount of degradation involved. The degradation of 
a subsystem will also have an effect on the other subsystems directly 
related to it. This means that subsystems feeding data to the 
degraded subsystem would be affected, as well as those subsystems 
receiving data from the degraded subsystem. 


1. System Supervisor (SS) 

The System Supervisor is the focal point of the entire informa- 
tion processing system associated with AIDS III. Since the System 
Supervisor is the message controller and router, none of the sub- 
systems Can communicate with any of the other subsystems if the System 
Supervisor fails . Under this condition, the entire AIDS III systamj ^l 
inoperative, there can be a limited amount of processing accom- 
plished, i.e., the Four Phase equipment can continue to be used for 
data entry, with verification data written out to tape. However, 
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at no card routing can be accomplished, queues will build up at the 
data entry/verification functions* The System Supervisor has most of 
the aspects of a real-time system controller* It does not route the 
cards automatically, but through instructions to people, and does not 
optically read the PCN at most stations* Effects of a System Super- 
visor failure on isanagement reports and the simulation model are 
recoverable, provided the data required is retained at the initiating 
subsystem until the System Supervisor is operational* 


2. Process Control Number and Image Capture Subsystem (PICS) 

The PIC subsystem is the initial controlling subsystem for AIDS 
III. The maximum rate at which cards can be processed through AIDS III 
corresponds directly to the rate at which the cards go through PICS. 

No processing can be started (other than opening and sorting the mail) 
until a process control number is assigned and both the Master Trans- 
action Record (MTR) and Transaction Record (TR) are created. If the 
PIC subsystem is run in a degraded mode, the cards will not be avail- 
able for down-line processing at the expected rate. If the subsystems 
down-line are degraded, the PIC subsystem can still be run at full 
capacity with an accompanying increase in down-line queues. 


3, Data Entry and Display Subsystem (DEDS) 

The fingerprint classification, wand-out, and data entry fun<?- 
tions are all part of the DEDS subsystem. Any up- line degradation has 
the immediate effect of a reduction in card flow to these functions. 
Without the classifications and data entry (DENT or VDENT) functions, 
the cards cannot be processed by any of the down-line subsystems. A 
degradation in DEDS has a minor impact on the wand-out (WAND) func- 
tion. All of the cards going through WAND are either being removed 
from the system to be routed for manual processing or returned to the 
contributor. The impact is felt in the delay in printing responses 
and in getting some of the wanded-out cards to the manual system 
(approximately 70% return to the AIDS I'll system at a later date). 

The impact at search review (SEAR) results in a delay in pro- 
cessing the response generation, rerouting of cards for a technical 
searches, re-searching, and final disposition routing. There will be 
an accumulation of data in the search statistics file, update files, , 
and response files because there will be no authorizations for updates 
processed. This file size overload must be considered. DEDS is 
critical for the timely processing of cards through the classification 
and data entry functions, while at WAND it is only marginally criti- 
cal. At SEM, the impact is primarily in the release of cards from 
the system. 


4. Subject Search and Response Generation Subsystem (SSRG) 

The SSRG subsystem is a critical entity of AIDS III. The subject 
search must be completed prior to routing the cards from the VDENT 
operation. Without knowing if a candidate was located, the card 
cannot be processed. The degradation of the SSRG has a serious effect 
on card flow and all interfaces with the TR file. Technical search 
and image comparison data cannot; be processed when the SSRG is down. 


5. Technical Search Subsystem (TSS) 

The TSS has less of an impact on the overall AIDS III system be- 
cause it handles no data transfers except those directly relating to 
the technical search function, and processes fewer cards than the 
DEDS, PICS or SSRG subsystems. The degradation of this subsystem 
does, however, cause a backlog in the Automatic and Semi-Automatic 
Fingerprint Reader functions (APRS and SAR). As the APRS function has 
some ability to separately store its results until the TSS subsystem 
is operational, the backlog here can be minimized. Since this sub- 
system and some components are running at a CPU -utilization of 100% 
(Ref. I, p. 6-70), there is no excess capacity to work off the queue 
build-up without scheduling overtime. The other subsystem affected 
directly by a degradation in the TSS is the Image Comparison Subsystem 
(ICS). Fewer than normal image comparison requests will be generated 
until the TSS is fully operational. As the image comparison and 
verification functions (ICI and ICV) are running at near capacity, a 
surge from the TSS will require overtime in ICI and ICV (and probably 
SEAR) if the backlog is to be reduced. 


6. Image Comparison Subsystem (ICS) 

A degradation of the Image Comparison Subsystem (ICS) will have 
the least effect on other subsystems and down-line functions. This 
subsystem does the final verification of a candidate match. The input 
is a result of either a subject or technical search resulting in the 
Identification of one or more candidates. A degradation of the ICS 
will cause the queues at search review (SEAR) to build. There can be 
no rerouting of cards or response generation, etc. from SEAR until the 
ICS results are complete. All of the other subsystems can function 
more or less independently from the ICS, providing those interfacing 
with I.CS can store the datp^to be processed until ICS is Operational. 
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SECTION IX 


SEARCH PERFORMANCE 


A. AUTOMATED SUBJECT SEARCH 

Automated subject search is a generic designation for the 
process of identifying and retrieving, in an on-line mode, a subject's 
record based on personal identification alone. 

1. Evaluation 

The performance of a subject search is evalutated in terms of 
its accuracy and reliability in making identifications or finding a 
candidate who will be positively identified. The FBI has required 
that the AIDS III Subject Search perform with a lower miss rate than 
the current manual name search (Reference 23). I'A order to make this 
evaluation, the current AIDS II Automated Name Search (ANS) was 
studied . 

The ANS was designed for two reasons: 

(1) To evaluate the performance of an automated search based 
on name and descriptive information, 

(2) To use this evaluation as a basis for estimating the 
performance of the automated subject search for AIDS III. 

The performance evaluation of subject search is based on AIDS II 
Volume Test results (Reference 44) which are summarized in Table 9-1, 
The results indicate that the subject search does perform better than 
the manual name search. 

The second purpose of the ANS (providing a basis for estimating 
the performance of the AIDS III Subject Search) is impractical, since 
the current ANS system is too unstable to permit any final conclu- 
sions. Prior to June 16, 1980, the ANS unit was accepting only those 
searches that could be handled in a day. No queue was allowed to 
build up. After that date, all inquiries qualifying for a subject 
search vere routed to the ANS unit. Full implementation of the auto- 
mated subject search was hampered by the Identification Division's 
inability to hire qualified people, software reliability problems and 
the limited capacity of the hardware used. The capacity problem was 
partially resolved by an upgrade of the computer hardware. The 
software is still being modified. The problem Of hiring qualified 
people is not easily solved, and it appears that it will be a contin- 
uing factor. 

Given the similarities between the ANS and the AIDS III design, 
it appears that the accuracy and reliability of the subject search 
will be superior to the manual name search. Although there are decided 
differences between the two systems, there is nothing to prevent the 
subject search from being operationally feasible. 
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Table 9-1. Automated Subject S<iarch vs Manual System Test Results 







Misses in Manual 
Found in Automated 
System 

Hisses in Automated 
Found in Manual 
System 

Type of 
Search 

Date of 
Report 

Searches 

Poss. 
No. of 
Idents 

Noik of 
Misses 

Miss 

Rate 

Z 

Misses 

per 

Search 

Miss 

No. of Rate 

Misses Z 

Misses 

per 

Search 

Criminal 

Name 

(Subject) 

01/25/80 

2356 

1262* 

120 

9.51 

0.051 

28 2.22 

0.012 

Civil 

Name 

CSubj ect) 

01/25/80 

296 

296* 

26 

8.78 

0.088 

5 1.69 

0.017 


*Based on tecb search, there were 136 missed for criminal and 10 for civil by both manual and 
automated name search* 
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Basis of Evaluat:ion 


In ad<iition Co Che volume CesC resulC6, Che evaluacion was based 
on a number of observaCions of Che manual name search and Che AIDS II 
AuComaCed Name Search* 

IC has been observed ChaC Che manual syscem conduces searches 
for poCenCial candidaces in Che following envlronmenCi; 

(a) The masCer file is composed of 3 by 5 inch file cards 
concaining Che name and full fingerprinc classification of 
each person represented in the criminal file^ plus any 
aliases which have been used, 

(b) The searches are conducted entirely by hand, and are based 
upon the names appearing on the fingerprint card. The 
accuracy of each search is dependent upon Che individual 
capabilities of Che clerk making Che search. 

(c) The update of Che master file is manual as well, making 
the integrity of the master file dependent upon the 
timeliness and accuracy of the update. 

(d) The only index to the file is the name and sex appearing 
on the fingerprint card. If more than one file card has 
the same name, primary and secondary fingerprint classifi- 
cations are used for greater discrimination. 

(e) A separate search must be conducted for each alias indica- 
ted on the fingerprint card. 

The design of the AIDS III Automated Subject Search is similar 
to the original design of the AIDS II Automated Name Search and 
Automated Correspondence functions in several ways: 

(a) Data entry screen formats and identification record re- 
sponses are substantially identical to those implemented 
in AIDS II. 

(b) All significant data elements being captured from Che 
fingerprinc cards and documents will continue Co be 
captured in AIDS III. 

(c) The four existing query types (i.e. , disposition, contri- 
buting agency, process control number, and miscellaneous) 
that are in use in AIDS II are sufficient for AIDS Hi. 

(d) Specifications for the AIDS III Subject Search are based 
on the functional requirements for ANS in AIDS II. It 
therefore appears that the search algorithms will be 
carried over to the AIDS III Subject Search. 
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There are several si|nl£ieanb ways in which the AIDS III Subject 
Search will differ from the AIDS 11 Automatfid Name Search? 

(a) Even though the algorithms to be used in the search will 
be the same, the application programs will most likely be 
rewritten due to hardware and software differences* 

(b) File updating will be on**line in AIDS Illf where it is 
batched in AIDS II. 

(c) The AIDS III design concept is assuming that the existing 
CPU loading problem can be resolved to efficiently service 
32 terminals per Four Phase Controller. Currently, 31 CRTs 
and one printer are being serviced by one controller in 
the ANS unit. The other controllers serve 20 to 29 CRTs. 

(d) In 1993, the Subject Search master file will be 3.37 tiroes 
as large as the current file (14.5 million compared to 4.3 
million). A reorganization of the name index is planned 
to keep degradation of response time due to this growth to 
a minimum. Rockwell has estimated that the CPU time 
required for a search will increase by a ratio of 2.80 
when the file has grown 3.37 times (Reference 21, page 11). 

(e) The file structures that will be utilized in AIDS III have 
not been determined. All indications are that a file 
reorganization will be necessary. The file structure will 
be dependent upon the hardware selected, the data base 
management system utilized and other operational consider- 
ations that are not yet clearly defined. 


3. Description 

The Subject Search and Response Generation (SSRG) Subsystem 
includes a search of the Computerized Criminal Name and Record File 
(CCNR), the updating of those files, the generation of user responses 
and related interfaces with the System Supervisor. 

The CCM is comprised of two separate but interrelated files. 

The Computerized Criminal Name File (CCN) contains one record for each 
FBI number, which includes personal descriptive data. The Compu- 
terized Criminal Record File (CCR) contains the arrest records, which 
is organized so that one record contains a separate date of arrest for 
a specific FBI number* 

There are four indexes to the CCN file. The Name Index is a 
hierarchical structure permitting access to CCN records on a basis of 
combinations of sex, name, and either high (blocked-out) fingerprint 
classification or date of birth. For a 15-50 million subject CCN file, 
the index will require 275,000 fixed length records and 20-40 million 
variable index entries for certain common combinations of retrieval 
parameters (Reference 1, pages 5-2, 5-3). 
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The other three ere unique identifier indexes; 1) FBI Nunber, 2) 

Social Security Number (88N), and 3) Originating Agency Identification 
(OKI) Number and Originating Agency Case (OCA) Number* The number of 
records in each of these indexes depends upon the number of occur- 
rences of the identifiers. For example » a l5~roillion subject file 
will have 15 million FBI number indexes , but less than 15 million SSN 
indexes. The ORI/OCA index records are purged from the index after 
one year. 

The proposed system is based on each search being allowed a 
maximum response time of 30 seconds. Seven seconds is allocated to 
the System Supervisor to process the request and initiate the search. 

The search itself is allocated fifteen seconds and the remaining eight 
seconds are allocated to the System Supervisor for processing the 
response* 

» 

I 

Figure 9-1 shows the logical flow of the Subject Search process. 

The subject search is initiated by the data entry verification 
operator (VDENT A or B) through the Data Entry and Display Subsystem 

(DEDS) and the System Supervisor. The VDENT operator enters the first j 

screen of data (60-80 characters) which is the data required for the ; 

search (i.e.j FBI Number. SSN, ORI/OCA, high-level fingerprint classi- | 

fication, date of birth, sex, race, place of birth and name). While | 

the VDENT operator is entering the arrest data, the CCN file will be 
searched. 

Searches can be initiated in one of the following ways; 1) FBI 
Number, 2) SSN, 3) ORl/OCA Number, or 4) name. The name search is the 
only one that is not based upon a unique identifier. A search by FBI 
Number has the highest priority, followed by the SSN, ORI/OCA Number 
and name search. 

A name search will automatically be initiated if no candidate is 
found for a SSN or ORI/OCA Number. A routine name search roust contain 
first name, last name, sex and date of birth. If the high level or 
blocked-out fingerprint classification is available, it will be used 
with the name and sex for the search. 

Potential candidates are retrieved from the CCN file based on 
the exact matches of the search criteria. These candidates are then 
scored, based on the other available information such as name, high- 
level fingerprint classification, date and place of birth, sex and 
race. The scoring process results in a relative score for each FBI 
number retrieved. The SSRG subsystem selects candidates based on a 
minimum threshold score of 1.0. The individuals whose score exceeds 
1.0 qualify as candidates. 

Figure 9-2 shows the internal and external functional data 
interfaces of the Subject Search and Response Generation Subsystems. 

A control function within the SSRG allocates the requests to the 
appropriate subject search modules . The SSRG then notifies the System 
Supervisor of the search results, and a response is returned to the 
VDENT operator to route the fingerprint card for further processing. 
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All the verified data that was entered by the VDENT operator is 
Stored in a Transaction Record (IR) file until a case disposition is 
made, When the System Supervisor receives an authorization from 
search review (SEAR) the TR file data is retrieved, and the CCNR files 
are updated. The appropriate response is generated and sent to the 
contributor. If the case results in an identification of an indivi- 
dual already in the data base, search data is used to subsequently 
update the data stored in the file for that individual. If an identi- 
fication was not made and a new FBI number is established for the 
individual, the associated data is stored permanently in the data base 


B, AUTOMATED TECHNICAL SEARCH 

1. Description 

Technical search refers to identification searches based on 
fingerprints as opposed to searches based on name or physical descrip- 
tion. The Automated Technical Search Pilot System (ATSPS) is a 
Rockwell -des igned and developed system intended to; 

(1) Test the automatic technical search concepts. 

(2) Produce performance statistics on fingerprint searching 
and matching operations in order to measure search 
accuracy (sometimes referred to as reliability) and 
selectivity in an operating environment. 

(3) Provide a basis for estimating the costs associated with 
an automated technical search system. 

The ATSPS has been evaluated relative to the manual system and 
as a stand-alone system. The only requirement placed upon AIDS III 
fingerprint search accuracy is that an automated search should perform 
better than a manual one (Reference 23). The test results indicated 
that the ATSPS does provide a lower miss rate than the manual finger- 
print search. 

Because of the limited size of the initial ATSPS data base, 
additional tests on other segments of the file have been useful in 
fully evaluating the technical search algorithms. Since the AIDS III 
fingerprint search is intended for use in on-line retrieval and file 
updating and the ATSP3 is operating in a batch mode, the interactive 
search algorithms, on-line updating of files, and computer interfaces 
have yet to be specified. The procedures used by the AIDS III System 
may be differtent than those in the ATSPS, but it is expected that they 
will i be equal to or better than those in the ATSPS. 

Figure 9-3 shows the loglical flow of the Automated Technical 
Search Pilot System and is described below. 

The Minutiae Master File is logically divided into 22 categories 
or units of fingerprint classification. As of August 1, 1980, the 
ATSPS Master File was limited t (3 one of the 22 fingerprint units of 


REQUEST 









th%e master file. The unit chosen (Unit lA) contains 560,415 male 
fingerprint cards, which are broken into 1972 segments or bins. The 
bin divisions were selected based on empirical analysis of the classi- 
fication frequency distribution of 1.3 million cards. For comparison, 
the entire 22 units contain approximately 22 million master finger- 
print card records. 

A request for a fingerprint search enters the system, is classi- 
fied by the National Crime Information Center (NCIC) fingerprint 
classification (process 1), and is entered into the system (process 2). 
The classification algorithms and search rules are applied to determine, 
as a function of NCIC-FPC and sex, the bins to be searched. Based on 
this classification, candidates are selected from the Minutiae Master 
File (process 3). 

The purpose of the next scoring procedure, the Filter (process 4), 
is to eliminate obvious non-candidate records in the selected bins and to 
choose the best subset based upon similarities of fingerprint 
classification, sex, date of birth, race and height. In the finger- 
print classification scoring portion, a score of minus 1 to plus 2 is 
assigned to each finger in the Master File subset. Each complete record 
(10 fingers) will then have a score between minus 10 and plus 20. 

Records with a score of 17 or higher are selected (process 5) to be 
evaluated further by the personal history and physical description data 
in the records. As result of this evaluation, a subset of records is 
sent to the Matcher scoring procedure (process 6)* 

In the Matcher scoring, the minutiae data of eight fingers 
f (omitting the two little fingers) on the request record is compared with 
^ each record in the Minutiae Master File subset. A raw score is assigned 
for each finger comparison, and a raw score total is computed for all 
records in the subset. The Matcher Evaluation Rules (process 7) increase 
the accuracy and selectivity of the Matcher selection. These rules 
weight the raw scores based on finger position and pattern type. One 
rule selects passing fingers (those that have more than a minimum score), 
a second rule weights the scores and a third rule ranks the candidates 
based on this weighted score. The third rule also adjusts the 
candidates' final scores by increasing the score of the top-rated 
candidates and reducing the scores of all others. 

In the ATS PS, the Interim Selection (process 8) evaluates each 
record in the subset data set based on the Filter and Matcher scores. If 
a candidate has high enough Filter and Matcher scores, the FBI number is 
listed and the candidate's fingerprint card is manually retrieved for 
positive identification (processes 9-10) 


2» Test Implementation 

ATSPS software testing began in May, 1979. To date, it consists of 
three phases: 

(1) Phase I (completed): Technical searches against known 
identification to determine reliability^ 
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(2) Phase II (in progress)} Fingerprint card searches pro- 
cessed in parallel through Unit 14 of the manual system 
and the ATSPS. 


(3) Phase III (test/evaluation mode)} New software is 

currently being tested and evaluated. Enhancements 
include limiting the size of the data set passing the 
Filter scoring, some Descriptor scoring (i,e., date of 
birth, race and height), NCIC-FPC scoring, an interim 
final selection process and update of the data base. 


Fingerprint records for first-time offenders assigned FBI 
numbers since* July 1, 1974, provide more information to the filtering 
algorithms (as shown below) because these records have been converted 
for name /subject search by AIDS II. 


Post July 1, lS/4 
Information 

Sex 

NCIC fingerprint 
classification 

Date of birth (year, 
month, and day) 

Race 

Height 

Minutiae 


Pre July 1, 1974 
Information 

Sex 

NGIC fingerprint 
classification 

Date of birth (year) 

Hot available 
in the ATSPS 
data base 

Minutiae 


3. Test Results 


a. Phase I technical search (against known identifications) 
test results are shown below} 


Number o f 
Searches 

Identifications 283 

Misses 20 

303 

The identification rate by data group: 
Post July 1, 1974: 97.7% 

Pre July 1, 1974: 90.1% 


Percentage 

93.4 

6.6 

100.0 


b. Phase II technical searches (in parallel with manual Unit 14) and 
comparative statistics to May 24, 1980, are shown in Table 9~2. 
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Table 9-2. ATSPS vs Manual Syacem Test Results 




Misses in Manual 
System Found in 
ATSPS 


Misses in ATSPS 
Found In 
Manual Systems 

Date 

of Report 

Searches 

Possible 
Number of 
Identifi- 
cations 

No. of 
Misses 

% 

Miss 

Rate 

Misses 

Per 

Search 

No. of 
Misses 

% 

Miss 

Rate 

Misses 

Per 

Search 

05-24-80 

27.681 

1,440 

354 

24,58 

0.013 

75 

5.21 

0.003 


In addition to the tests run in Unit 14. three representa- 
tive vertical slices of other areas of the data base were 
selected to make some additional tests. The purposes of 
these tests were to; 

(1) Make a preliminary determination of search reliabil- 
ity in portions of the file which provide extremes 
of classifications, or which provide special prob- 
lems for the minutiae capture/usage process, 

(2) Determine and quantify the types of misses which 
occur in each area, 

(3) Make a preliminary determination of Automated 
Technical Search selectivity in each area. A radial 
loop-intensive segment (in Unit 3), an ulnar 
loop-intensive segment (in Unit 5), and a balanced 
area of female prints (in Unit 22) were chosen for 
these tests. The results of the tests are 
summarized in Table 9-3. 

The results indicate that the search algorithm does maintain its 
reliability and selectivity when performing searches in areas outside 
Unit 14. 

c. Phase III was brought up on July 21, 1980 for testing 

(Phase II will continue until the new Phase III software 
is validated, } Because no final test results were avail- 
able. the evaluation of the technical search algorithms is 
based upon the results of Phase II tests. However, 

I preliminary results from Phase III testing indicate that 

the software is improving the performance of the ATSPS. 
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Table 9-3. Summary of the ATSPS Tests Outside Unit 14 





UNIT 

3 

UNIT 5 

UNIT 

22 


Previously 

Identified 

Not 

Previously 

Identified 

Previously 

Identified 

Not 

Previously 

Identified 

Previously 

Identified 

Not 

Previously 

Identified 

NUMBER OF SEARCHES 

70 

108 

128 

93 

105 

107 

FILE SIZE 

78,405 

78,405 

114,230 

114,230 

106,773 

106,733 

IDENTIFICATIONS 

67 

- 

119 

3 

102 

1 

reliability 

962 

- 

932 

- 

972 

.. 

CONSOLIDATIONS 

2 

- 

2 

- 

5 

— 

FALSE DROPS 

1 

15 

8 

18 

4 

17 

FALSE DROPS/SEARCH 

0.014 

0.14 

0.06 

0.19 

0.04 

0.16 
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4. 


Enhancements 


The AIDS III Technical Search will incorporate enhancements that 
have been designed for Phase III of the ATSPS. Figure 9-4 shows the 
revised logic flow of the Phase III ATSPS, This is also the concep- 
tual logic flow for the AIDS III Technical Search, 

As in Phase II, the NCIC fingerprint classification is assigned 
to the request card (process 1) and entered to the system (process 2). 
The bins are selected (process 3)> and filter scoring (process 4) and 
selection (process 5) take place. The number of records which may 
pass the Filter in a search is now limited to 250 (Reference 1, pages 
5-46 ‘y. 

In Phase III, the NCIC-FPC (process 7) and some Descriptor scor- 
ing (process 9) are taking place in parallel with the Matcher scoring 
(processes 6, 8), The NCIC-FPC Scoring (process 7) will develop a 
score based upon the similarity of the search FPC (and references) to 
the FPC of each file candidate, NCIC-FPC Scoring involves the develop- 
ment of a distance measure based upon the degrees of disparity (or 
similarity) between the NCIC-FPC (and references) of the search print 
versus the file print. Individual finger classification distances are 
combined to produce a card level distance for each candidate. NCIC-FPC 
scores are then derived as a function of the card level distances, the 
rank ordering of the candidates, the distance differential between the 
file candidate being scored and the file candidate which has the 
smallest distance of all those in the search (Reference 35, page 12, 
Reference 36, page 16), 

Fourteen descriptors will be incorporated into the Descriptor 
Scoring algorithm (process 9), These descriptors are included in the 
information normally recorded on a subject's fingerprint card and sub- 
sequent captures by the data system (Reference 1, pages 5-51). It 
appears that this data will be stored with the minutiae data for each 
subject. File update procedures for this data have not been addressed 
by Rockwell. 

Rockwell has categorized the descriptors into three categories. 
Physical descriptors include sex, race, eye color, hair color, height, 
weighty scars, marks, tattoos and skin tone. Personal history descrip- 
:tors include date of birth, place of birth. Social Security number and 
name. Criminal history descriptors include place of arrest and type 
of offense (Reference 1, pages 5-51 thru 5-53). 

A Final Selection procedure (process 10) performs the final, 
automated determination as to which candidates (if any) will be 
selected for comparison with the inquiry search card (processes 11, 

12). Identifications and non-identificationS are handled as appro- 
priate (Reference 1, page 5-84). 
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Figure 9-4. AIDS III Technical Search 
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SECTION X 


DATA BASE MANAGEMENT 

The data base structure and tnanagement of that data are integral 
parts of any information system, especially one of the size and 
criticality of the one proposed in the AIDS HI System Concept » The 
development and maintenance costs of supporting the information 
processes in AIDS III are significant. They are a nmjor factor in 
developing and utilizing the data being accumulated for identifying 
individuals. 

A make/buy evaluation of connercially available general-purpose 
Data Base Management Systems (DBMS) for use in the AIDS III System 
should be made. In the documentation received, there was no evidence 
of such an evalution, nor that any data base management system tech- 
nology assessment had been made. If evaluations have taken place, the 
results should be reexamined to determine the exact justification for 
rejecting the use of a commercially available DBMS. If such an 
assessment has not taken place, it should be completed prior to addi- 
tional expenditures in the development of specialized software to 
support the FBI Identification Division function. This recommendation 
is based upon the following considerations: 

(1) AIDS III file structures are compatible with a 

general-purpose DBMS. 

(2) There are cost savings in implementation and maintenance. 

a. automatic file access control and data security. 

b. automatic audit trial and backup. 

(3) Upgrades have a minimum impact. 

a. operating systems. 

b. CPU. 

c. disks. 

d. data element revisions and additions. 

(4) DBMS parameters can be adjusted to meet specific needs. 

(5) Query languages are available. 

The use of a commercially available DBMS does not imply that a 
single physical file or data base must be established. The rationale 
behind the recommendation is to establish the required number of 
physical data bases or files with coninon software support, and to 
increase the ease of handling logical interfaces. 

Prior to the evaluation, a set of functional and data usage 
requirements must be developed for each logital file anticipated in 
the system. How the various commercially available DBMSs meet these 
requirements on a cost-effective basis will be a major consideration. 
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A. 


GENERA!, COMMENTS ON GENERAL-PURPOSE DATA BASE MANAGEMENT SYSTEMS 


While the cost per bit of storage and execution cost per 
instruction have both been decreasing i the same trend has nob been 
true of software development. Since software development has con- 
tinued to be a people-oriented activity, a higher percentage of Che 
total system cost in acquiring and developing a computing system is 
accruing to software development (Reference 28). 

General-Purpose Data Base Management Systems are characterized 
as software packages which provide a flexible facility for accomnoda- 
ting different types of data files and operations while requiring less 
programming effort than conventional programming languages. A DBMS 
provides a software environment which is not tied to a particular set 
of application programs or files. This provides tremendous flexi- 
bility in utilizing program maintenance personnel. 

In selecting or developing a software capability for data pro- 
cessing functions, there are two extreme alternatives: 1) Design and 

implement the system by tailoring it to a specific application, 
without using any prepackaged software or 2) utilize a commercially 
available DBMS, and build any necessary additional functions with 
application programs (Reference 22). 

The first way necessitates a large initial investment in data 
base system design and implementacion. Although a great deal of this 
effort has already been invested in AIDS II, over $5.9 million remains 
to be invested in computer subsystem software development, In the 
development of a homegrown data base managment system there is gener- 
ally a substantial time lag between system conception and implemen- 
tation, especially if the hardware and operating systems are not known. 

The reliablity and dependability of commercially available DBMSs 
is continually increasing. Experience at JRL in the development of 
homegrown data base management systems vs commercially available sys- 
tems has shovm that: 1) implementation times for commercial systems 

are shorter, 2) reliability of commercial systems has been equal or 
higher, and 3) costs have been less than if the systems had been 
developed in-house. 


B . FILE STRUCTURES 

It does not appear that the structures of the files proposed for 
AIDS III (Reference 14) are of a nature to preclude the use of a DBMS. 
File maintenance and data updating is always complex. Reutilization 
of freed storage space in the data base is automatically managed by 
m>st DBMSs and is transparent to the user. Special utility programs 
to do this will not be required. Establishing functional requirements 
for the AIDS III data bases will greatly assist in the development of 
hardware requirements. 
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ORIGINAL PAGE IS 
OF POOR QUALITY 


COSTS 


C* 


An important fact to rcowmber when designing a coraputer-based 
svstem is that hardware is cheaper than software development, roainte~ 
nance or operation costs, tf the present trend continues, this 
differential will be greater and greater (Reference 28). 

The proposed AIDS III system appears to treat the problem of 
data base management as a software coding exercise. Large amounts of 
specialized assembly language and COBOL software arc proposed which 
would be sensitive to environment and data changes, and would tend to 
maximize both new development and long~term maintenance costs. 

The basic problem to be solved by the AIDS III system is that of 
managing an inquiry into a large collection of highly sensitive data. 
The system proposed is a highly complex simulation of the manual 
system containing electromechanical devices, electronic hardware and 
human interfaces. If it is to support the FBI Identification Divison 
in a cost-effective manner into the roid-1990's, it must be able to 
respond to change, both technical and societal. As time passes, 
equipment will be changed due to age and advances in technology. 

Future social pressures may cause changes in the data and in its use. 
Hence, the data base must remain adaptable and the system flexible. 

Programming costs arc an important factor In implementing AIDS 
Illi One means of determining program development time and costs 
involves the average number of lines-of-code (LOG) produced per hour. 
There are various standard rates that can bo applied, but three 
sources: Johnson (Reference 29), Brooks (Reference 30) and Walston 
(Reference 28) are fairly consistent in stating LOG productivity 
rates. Batch systems are in the 6000-7000 LOG/man-year range, com- 
pilers, 2000-3000 LOG/man-year, and operating systems 600-800 
LOG/man-year. Recognizing that a data base managment system is more 
complex than a batch fiystem, but not as involved as a compiler or an 
operating system, an extrapolated LOG productivity rate could be in 
the 4000-5000 LOG/man-year range. Rockwell has stated that the coding 
will probably be in assembly language which, being a lower level 
lanpjsge than COBOL, could have a different productivity rate. Using 
5, §00 LOG/man-year as an assumed rate and 500,000 lines of code 
estimated for the task (Reference 15), this equates to about a lOO 
man-year effort. If only one-quarter of the estimated 500,000 LOG are 
to be devoted to the data base managment system and related inquiry, 
backup and operational procedures, 25 man-years will be applied to 
development of the data base management system. Given the estimated 
cost of $76,000 per man-year of programming effort (Reference 34)', the 
development cost becomes $1.9 million. 

High-level software maintenance people will bu required to 
maintain the various data base files. The more varied the file 
structures in a system, the wider the range of software maintenance 
skills and knowledge required. 
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The security of the information being utilized in AIDS III is 
critical, protection not only from unauthorized inquiries or data 
manipulation« but also in the form of audit trails | baekup) restoral 
facilities and system integrity. Security is a major concern f^ith 
computer systems and is not sufficiently addressed in AIDS III. 

Today's commercially available general-purpose Data Base Management 
Systems provide this as a standard feature. 

Data protection and security involve insulating a data base from 
system failures, vandalism, natural catastrophes and the like. This 
Includes backing up multiple files containing tens of gigabytes (10^ 
bytes) of data and restoring them in a timely manner. DBMSs provide a 
natural facility in this area. 


D, CONFIGURATION UPGRADES AND DATA ELEMENT REVISIONS 

When a system is developed for a specific application utilizing 
a specific hardware configuration, it may not be flexible and respon- 
sive to internal and external environmental changes. Upgrading 
central processing units (CPU) or storage hardware, or using an 
improved version of an operating system to take advantage of the 
continuing improvements in the state of the art can have significantly 
less effect on a comnercially available DBMS than on a homegrown 
system in terms of both effort and costs expended. 

Modifications or changes of data elements in the system will 
require reprogramming and possible file restructuring. All data now 
in the system may not bo needed or required in 1990. If a commercial 
DBMS is structured to permit elimination or separate handling of that 
data, additional storage space can be freed and used for new file 
record s . 

DBMS technology uses separate logical and physical data base 
descriptions to completely insulate user applications from changes to 
the data organization and hardware environment. In the AIDS III 
System Concept (Reference 14), it states that assembly language DSECT 
macros and COBOL record descriptions will be used to provide data 
independence. This means that, whenever a record element is changed 
these descriptions must be changed, and all programs referencing these 
data must be recompiled, retested, and recertified. If, for example, 
a change from a 3 to a 2 byte minutiae file format is desirable, this 
could require significant effort in making modifications to existing , 

programs. DBMS technology requires modifications only to affected ^ 

schemas /subschemas (data descriptions) and furthermore insulates users 
from hardware upgrades, data reorganization, and all but major record 
restructuring. 
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B, ADJUSTMENTS TO MEET SPECIFIC USER NEEDS 

Some DBMSs are structured to ifaclUtate whatever specific 
modifications may be necessary for unique search processing. In 
information systems utilizing computers it is important to identify 
any areas in the system where data flow is inefficient or ineffective » 
and those areas where a slight Improvement or modification in either 
the software or hardware structure will produce a significant through- 
put improvement. Generally speaking^ commercially available DBMSs 
provide statistical information and control information that can be 
used to improve processing of throughput time. In addition^ the 
acquisition of a data dictionary^ query language, report writer, etc.. 
Could greatly extend and enhance the capabilities of the AIDS III 
system while providing useful management information upon request 
without extensive programning. 

The structure of the data bases for various logical and physical 
files roust be such that they can handle greater than expected capa- 
cities through the addition of hardware, rather than needing repro- 
gramming. Reference 14 (page 5) states *Vthe tremendous volumes of 
records to be processed by this system dictate that the files be 
designed in a manner which will optimize processing efficiency." 

While this statement has validity when addressing processing through- 
put. it does not address the software management complexity introduced 
by the development of a homegrown system. It precludes or presumes 
that commercially available DBMSs will be inherently slower and 
adversely impact the ability of the overall AIDS III system to process 
the inquiry in an acceptable period of time. In reality. DBMSs can be 
tuned to meet the specific requirements of the user. 

It is possible that a commercial DBMS package may require 
slightly greater computer resources than a homegrown, tailored 
system. The acquisition cost of more powerful hardware should be 
considered as part of the evaluation. This additional cost can be 
offset by savings in software and by improved implementation sche- 
dules. In addition, the configuration of the system may be such that 
any additional resources required are already available. 


F. QUERY LANGUAGE 

In the AIDS III concept, a number of inquiry requirements are 
identified and data files established to provide management infor- 
mation. These queries will require computer programs to interface 
with the files involved. There are also & number of files that 
interact with each other and demonstrate a high complexity for those 
inquiries known today. Inquiries handled in the future may be best 
served by the use of the query language available as part of a 
selected DBMS. In addition to laanagement and statistical informa- 
tion. a flexible query capability could enhance the performance of the 
on-line query (QUERY) function. 


Reference 14, page 5 states that there are . . no plans to 
incorporate a generalised query capability to the AIDS III system. 

AIDS III is a highly specialized system which is necessarily dedicated 
to the processing of fingerprin^l cards and related documents. Other 
uses of the system are entire ly| secondary to this primary purpose.” 
While a general -purposf/ query ^Apability is not banned, "additional 
specialized query capubilities/'will be incorporated. . .should the need 
arise” (Reference 14). To promote standardization and facilitate 
expansion, it appears that a query language with syntax tailored to 
AIDS III is already planned. Based on JPL's experience in information 
systems, the probability of query capabilities being needed is high. 

As sophistication and a better understanding of the capabilities of 
AIDS III are developed, there will be an increased inquiry/ demand. 


G • 


CONCLUSION 


For the above reasons, it is recommended that a make/buy evalu- 
ation of the use of a commercially available general-purpose Data Base 
Management System be made and incorporated in the implementation of 
AIDS III. The implementation of p, data base management system proto- 
type could greatly assist in this evaluation, and Would;\be useful in 
determining the full benefits of commercially available general- 
purpose Data Base Management System. 
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SECTION XI 


FILE CONVERSIONS 


Implementing AIDS III will require restructuring and reformat- 
ting the Minutiae Master File (MMF) and Computerised Criminal Name and 
Record (CCNR) files. The same basic procedures (including testing) 
used in establishing the Automated Technical Search Pilot System 
(ATSPS) will be employed for the AIDS III conversion^ Data file 
structures and format requirements will vary depending on the hardware 
and data base technology used. >A brief general discussion of Rock- 
well's file conversion concepts can be found in Reference 16. Conver- 
sion of source data and data files is addressed In Reference 12. 

Conversion of the fingerprint card master file to microfiche is 
mentioned in Reference 2. It was estimated that the conversion will 
take 15*5 months to convert. The fingerprint card/microfiche conver- 
sion plan briefly diecusses costs, time and resources but does not 
discuss how the conversion is to be done. 

The complexity, scope and coordination required for a project of 
this size cannot be overemphasized. A comprehensive validation test 
and transition plan is planned for AIDS III, although it has not yet 
been developed. Details (both technical and management) for the 
creation of AIDS III data and microfiche files require further consi- 
deration and development. 


A. MINUTIAE MASTER FILE AND COMPUTERIZED CRIMINAL NAME AND RECORD 

FILES 

O 

As of July 16, 1980, the Technical File Conversion Unit of the 
Automation and Research Section had converted 12,701,591 fingerprint 
master cards into machine-readable format for minutiae data. This is 
out of a planned conversion of 14,500,000 cards. There is no expected 
additional card conversion necessary when implementing AIDS III. Depend 
ing upon the hardware selected and the software utilized in establish- 
ing and maintaining the minutiae files, a conversion from the current 
format, file structure and equipment will be necessary. Data from the 
technical master file conversion is being archived and maintained on 
magnetic tape. 

The information contained in the Computerized Criminal Name and 
Record (CCNR) file is being accumulated and maintained by the AIDS II 
system on an ongoing basis. Rockwell anticipates that the CCNR \ 
organization and file structure will be different in AIDS III than in 
AIDS II, making a CCNR file conversion necessary (Reference 14, page 
7). The CCNR data will be,. extracted fr,pm data and files in existence 
at the time of AIDS ill implementation. -The CCNR data will be extrac- 
ted directly from the Technical Master Fi».’i,'s archived tapes and 
existing CCNR files. At the time of the yAlDS III operational gtart- 
up, the data bases will bv2 current and wiH' contain records thUt have 


been subjected to extensive editing. Programs to extract data from the 
AIDS II CCNR files and the Minutiae Master File (MMF) created during 
the Technical File conversion do exist and have been utilized 
extensively by the Avitomatic Technical Search Pilot System (ATSPS). 

The value of these programs however, depends upon the hardware and 
data base management technology ultia^tely selected. A detailed plan 
for the management, development, test and integration is required 
before a transfer from the AIDS II operational and AIDS III test modes 
to the proposed AIDS III System can be expected. 

Data entry screen and identification record response formats are 
expected to be substantially identical to those implemented in AIDS II 
(Reference 14). Data screen file formats do not appear to require a 
conversion but, depending on the final hardware and data retrieval 
system selected, response data in the CCNR files may require a reorga- 
nization, 

A data base upd'ite method has not been formulated for the AIDS 
III design. In Refetl^hce 14, it is stated that it "should be assumed 
that updating will be* performed on-line." Transactions will be 
accumulated on a serial file device. In the event of a system mal- 
function, the file can then be rebuilt by a combination of restoration 
and re application of the interrupted transaction. Extensive develop- 
ment work is still required in this area. The implementation of a 
reliable and effective on-line data base update methodology is criti- 
cal to the success of ’AIDS HI (See Section X, Data Base Managemsnt)! 

The standards for software development will be based on the FBI 
Technical Services Division Systems Development Standards manual that 
Rockwell understands is now in preparation./ A review of these stand- 
ards was not included in the evaluation. 

MMF and CCNR file conversions should not be considered as simply 
extensions of the ATSPS conversion with some fine tuning added. The 
size and complexity of AIDS III is far greater than ATSPS. It is 
implied that the programs used in the ATSPS (where applicable) will be 
used in the AIDS III conversion. It may be more effective to utilize 
the system concepts but rewrite the programs, in view of today's 
technologies. Whatever route is taken, the MMF and CCNR file conver- 
sions will require a level of design testing and implementation 
nianagement which is not detailed in the implementation plan at this 
time. 

It is implied that the FBI Technical Service Division Will be 
responsible for the development of the design requirements (Reference 
14, page 17). The line of responsibility between the concept or 
functional requirements of the system and the System design require- 
ments is not clear. Additional conceptual and design effort is needed 
before reliable time and cost estimates for data file conversions can 
be established. 
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B. 


MICROFICHE FILE 


The only reference to fingerprint card conversion to microfiche 
images was found in Reference 2; page 164. CobtSf resources and 
schedules were generally addressed. It is stated that, working 15 
hours a day, it will take 15,5 months to convert the estimated 14 
million fingerprint cards (from mid-1980 to late-1981). No discussion 
of how this will impact the ongoing system or the computer subsystem 
interface requirements is noted. More detail is required in this 
area. Converting fingerprint cards to readable microfiche images is a 
critical activity and will require an extensive effort. 
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SECTION XII 


FACILITIES 


Development of the facility requirements for the AIDS III System 
will req.'|iire additional work before a realistic evaluation of require- 
ments ca| be made. AIDS III concept changes are not yet fully reflec- 
ted. It is recommended that a further review of safety and fire 
protection requirements be made. 


A. EQUIPMENT LOCATION 

In the AIDS III System Concept (Reference 1), it is not clear 
whether Figure 6.6-6 is an update of Figure 6,6-1 or is complementary 
to it. Much of the computer hardware shown in Figure 6,6-1 is not 
reflected in Figure 6.6-6, while the process control number machines 
and the microfilm image capture equipment are shown in Figure 6.6-6. 

The revised plan (Reference 8, Figure 8-4) indicates a larger 
floor area and does not specifically address the proposed computer 
central processing units (CPU) or front end processors (PEPs). The 
floor space requirements presented in Reference 1, Table 6.6-1 must be 
updated to reflect the space requirements for the work cell, the 
transportation mechanisms, and the number of work stations required. 

In addition, safety requirements may require additional considerations. 
Consideration of interfloor modes of transportation as well as between- 
station conveyor systems need further examinatiq4». 


B. CARPETED FLOOR 

Placement of carpeting on a computer room floor is not recom- 
mended. Based on the experience JPL has had in its numerous computer 
areas, there is a tendency for dust and dirt to gather underneath the 
equipment and, in general, carpeting does not promote the cleanliness 
required for a computer room environment as well as tile flooring 
does. Carpeting in normal office work areas, including those having 
terminals, is recommended. 


C. SAFETY CONSIDERATIONS 

The floor layout presented in Reference 1, Figure 6.6-1, with 
all computers grouped in the center of the building, may generate a 
safety hazard. Discussions of permanent walls and partitions, air- 
conditioning ducts. Various subfloor cables and glass walls around the 
computer room do not reflect the application or consideration of RP-1, 
Standard Practice for the Fire Protection of Essential Electronic 
Equipment Operations, issued August 1978, by the U.S. Department of 
Commerce, National Fire Prevention and Control Administration (Refer- 
ence 43). ■ 
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Using the same ducts to run air conditioning from the computer 
area to the employee area raises the possibility oT smoke being 
transmitted through the building or work areas via these ducts in the 
event of a fire. Provisions could be provided to expel smoke directly 
to the outside of the building in the event of a fire. RP-l should be 
reviewed for further consideration in this area, In addition» if 
water is used as part of the air-conditioning system, appropriate 
water detection devices should be placed in the raised floor area to 
detect possible water leakage. 

Inetallation of any power transformers or Uninterrupted Power 
pbpply (ups) batteries on the same floor or within close pvomimity to 
the work area could also present a hazard from fire and resulting 
smoke. It is not recommended that power transformers or associated 
power generating equipment of this nature be located near either the 
computer room or the general working area. 


D. FIRE CONTROL 

The discussion of fire prevention in Reference 1, Paragraph 
6.6.7 should also be reviewed in light of RP-1, Using a Halon fire 
extinguishing system within the control room should be reconsidered, 
Halon is not a reconmended method for controlling fires within a NASA 
computer room. This is due to the toxic nature of Halon, and the time 
delay required for the evacuation of persons in the fire area (Refur= 
ence 40). In addition to CO 2 extinguishers mounted on the walls for 
electrical fires, H 2 O extinguishers should be available in the event 
of paper fires (especially those in wastepaper baskets), 

The use of a "wet*' sprinkler system may be an alternative. 
Problems in such a system are caused by contaminants in the water, 
rather then the water itself, which can be controlled by regular 
flushing of the water system. 

In order to ensure the best available fire protection, fire- 
stops should be in the walls between the computer CPU area and the 
employee working area. This includes the ducts through which all 
interconnecting cables pass, including cables between computers and 
their assigned peripherals. Cabling for terminals outside the; com- 
puter room should also piiss through fire-stop control walls. There 
should not be glass walls between the computer area and the employee 
working area. 


E. POWER SUPPLY 

Using the UPS as a met|»odology to shut down the computer system 
until facility power is restored appears to be reasonable. Some 
questions arise, however, regarding the exact power configuration that 
would ultimately be required, which will depend upon the exact equip- 
ment being used. UPS should hot be utilized beyond graceful system 
shut-down. Since lights, air-conditiouing and power for individual 


terminals would not be avallablei it does not seem practical to keep 
the computer running if it can be gracefully shut down. It is recom- 
mended that procedures to havidle the controlled shutdown and start-up 
of the system and be developed and thoroughly tested to ensure that no 
data is lost in the input or inquiry front-end pro- cessors. Since 
pot*er cables and the like are located under the floor, smoke detectors 
should be installed at the same level. 


F. OTHER 

As previously mentioned in the report, consideration must be 
giyhn to the need for controlled lighting at the image comparison and 
vets^fication function (ICI and ICV) and the Semi-Automatic Readers 
(SAR). Activities associated with *mage capture on microfilm (MFILM) 
and microfilm processing (FLAB) should be in a separately enclosed 
room, properly ventilated, with appropriate fire protection. 
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APPENDIX A 


OPERATIOMAI* COMPONENT SUMMARY 


Tabu A-1 coiitaini a auimary ot the basic data gathered for each 
operational component in the AIDS III System Concept. The data 
contained for each component includes: 

Acronym : 

An abbreviatiem used in the system to identify the opera- 
tional component# Table A-1 is in acronym order. 

Description : 

Complete description of each component can be found in 
Appendix G. 

Service Rate : 

The processing rate of a single unit in the component. 
Service Distribution : 


Constant or exponential service distribution rate within 
the component. 

Number of Units : 

The number of units proposed in the AIDS III System 
concept. If a component has units in the work cell# the 
number of units in each work cell is also shown. 


Interfaces ; 

Input: The source of the data entering the component 

on an hourly basis. This is broken down by 
percentage and volume based on workload 
guidelines. Interfaces with computer sub- 
systems reflect hourly messages and bytes/ 
message transfer rates. 


Output: 




MTBF: 


The destination of the data leaving the 
component on an hourly basis. This is broken 
down by percentage and volume based on work 
load guidelines. Interfaces with computer 
subsystems reflect hourly message and bytes/ 
message transfer rates. 


(Mean Time Between Failures) The average value of time 
intervals between successive failures of equipment over 
the total operating time. 
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MTTR t 

(Mean Tint To ReiCore) The time from detertelnation of 
equipment failure to locating the failure and repairing it. 

% Availability^ 

The probability that the equipment will be able to petform 
itf intended function. 
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Table A-1. Operational Con^jonent Stimmary 


OPERATIOKAL CaiPONENT 


DESCRmiON 


SERVICE 
RATE® - 


pza 

TOTAL WORK 
CELL 


INTERFACES 


APRS Automatic Fingerprint Reader 250® 
System 


AOTOCXIR {Automated Correspondence 


100 Pieces 


AUTORESP Autraated Response 
Generation 


2000 (Output 
(Doctseents) 


CLASS-A Classification-A 


( INPUT 

[CS0RT-11X)Z (1033) 


Total-2410 pieces 

• F/P card-1 

• SrAR(25)-192 (A68) 

• ai3C(19)-122 (282) 

• W^INDCS) -3Z (83) 

• Oocunents 

• Vl>^-B(34)-2r (60: 

• AimOKESP(26) 

• HIENTS-35Z (837) 

• N/IDENTS-28Z (680) 

System Supervisor 

• 1517 messages 

• A\t bytes/aesSage 
SSRC 

• 1512 messages 

• Unk by tes/aessage 


ENCK-lOCiZ (720) 
ENCK-IOCS (U37) 


total-1033 

SAR-3Z 

SEAR-971 <1003) 

TSS 

• 1033 messages 

• 2000 bytes/message 
System Supervisor 

• 1033 messages 

• 10 bytes/message 

HAIL R0(»l(l)-2410 
pieces 


HTBE^ 

(HRS) 

Kmi® 

(ras) 

X 

AVAIL-. 

ABiLirr 

700.0** 

106.9^^ 

4.0^ 

2.0^ 

99.43 

^.82 


AUTOCDR-Total 15i7 
(Output i)ocuments) 

• IDENTS-5SZ (837) 

• N/1DESTS-45Z (680) 
Kamial-294 Index Cards 

(plus unknown # of 
new alias) 

DENT-A-IOOZ (720) 

DENT-A-IOOZ (1137) 

DEDS (Legible) 

• 1137 nK^ssages 

• 80 bytesAmessage 
(avg) 

System Supervisor 

• 1137 messages 

• 10 bytes/message 


Unless otherwise noted the data reflects cards at a per hour rate 

» Constant Rate 
£ ^ Exponential Rate 

*^Values and X splits may not agree due to X rounding 

^Hean— Tine-Between—Fallure (excludes computer sub^stem components) 

®Hean-Tlaerto-Restore (Includes Response Time) 


1) Does Not Include Subsystem or Transpertation Availability Data 

htbf 

^ MTBF ItlTR 

®JPL Study Data (Current Service Rate — 165 cards/hr« plus Rnckwell p-roposed 
APRS modifi cat Ions) w 

Rockwell 04ita 

^JPL Study Data 

^TOZ of cards leaving the function for the Manual System reenter the Automated 
System^ 


i 





Table A--1. Operational Component Summary (Continued) 


OPERmCNAL COMPONENT 


DESCRIPTOR 


CLASS B |Classl£lcatioa-5 


CLASSIC Classi£lcacion*>C 
CLCK Classification Check 


SERVICE 

RATE® 


CSORT Cenceriine Sort 

DATE STP Date Staap, Count and Log 

DENT-A Data Entry-Cards 


PER 

■TOTAL WORK 
CELL 


INTERFACES 


rotal-395 
roENT-A-l35Z (335) 
SEAR-15X (60) 


NA DATE SXP-IOOZ (145) 

3 rotal-1315 


[rotal-1315 
VDENT-A-I)5Z (852) 
OASS B-TO?' (395) 
SEAR-5Z 1(68) 


1635/day E 

(Docunents) 


DENT-B jData Entry-Docuraents 


HA jCLCK-lOOR (1033) 

HA MAlL-lOOt (1627/day) 


jTotal-2254 
|BLO-32Z (720) 
fcLASS-A-50^. (1137) 
(eNCK-182 (397) 


30 CNK 42 HA;; JeSCDOC-ICIOS (1220) 

Docuaents I 


CLOC-IOOZ <395) 

BEDS (Legible) 

• 395 aessages 

• 80 bytes/aessage 
avg) 

System Supervisor 

• 395 messages 

• 10 bytes/message 

Manual-lOOZ (145) 

Total-1315 
CSORT-79Z (1033) 
ALTOCOR-21% (282) 

BEDS (LegibU) 

• 1033 »e.«iaages 

• 80 bytes/message 
DEDS ( Illegible) 

• 282 messages 

• 20 bytes/message 
System Supervisor 
(Legible) 

• 1033 messages 

• 80 bytes/message 
System Supervisor 
(Illegible) 

• 282 messages 

• 20 bytes/message 
TSS 

• 1033 messages 

• 80 byres/message 

I AFRS-IOOZ U033) 

I SAR-Few 

I CLASS-C-IOOZ (145) 


VDENT-A-IOOZ (2254) 

DEDS (Search Parameters) 

• 2254 messages 

• 160 bytes/message 
(Avg) 

System Supervisor 

• 2254 messages 

• 10 bytes/mi'ssage 

VDEKT-B-IOOZ <1220) 

BEDS (Sean h Parameters) 

* • 1220 messages 

• 160 bytes/message j 
System Supervisor 

• 1220 messages I 

• 10 bytes/message J 


MTBF^ 1 

MTIS* 

(HRS) 

(HRS) 

7000 1 

2-0 












Table A-1. Operational Component Summary (Continued) 


> 

I 

Ov 


OPERATIOKAL COHPONENT 


ACRCNYK 


MAIL 


MFILM 


PClf 


PCI? 

APPL 

Qc ; 


mm 


DESCRIPTION 


Open ILiiX and Sort 


Image Capture Ilicrofilis 


Process Control Number 
Application ^ Cards 


Process Control Number 
Appl'ication - Documents 

Quality Control Cbeck 


On Line Query 


SERVICE 


720 


500 


2000 


1300 

(Documents) 

ISO 


10 Calls 






NO. UNITS 


I 


PER 

INTERFACES* 

"■ ToTaL 

WORK 

CELL 

INPUX^ 

OUTPCT^ 

6 

NA 

Post Office 43*677/day 

DATE STP-42 (1.627) 



• 29,177 F/P Cards 

PCN APP-33Z (14,500) 



• 14,42$ Criminal 

PCN-632 (27,550) 



• 13.12$ Civil 

• Criainal-522 



• 1,627 Other 

(14.325) 



• 14,500 Documents 

• Civil-4ffi£ (13,225) 



• 10,050 Dispositions 

• 4,450 Miscr 




Requests 


6 In- 

NA 

Total-3037 

local-3037 

ciud- 


PCN-80Z <2449) 

IjC-802 (2449) 

ing 1 


SEAR-102 (294) 

Temp, hold-102 (294) 

square 


■Temp, hoId-IOZ (294) 

Perm, file-102 (294) 

used 



PICS 

for 



• 3037 messages 

t^p. 



• 6 hytcs/message 

hold 



System Supervisor 

and 



m 3037 messages 

perm. 



• 6 bytes/message 

file) 



ssw; 




• 3037 messages | 

• 6 byte/message 4 

9 

2 

NA 

MAIL-1002 (2449) 

MFILH-I002 (2449) 



• CrittinaX-522 

PICS 



(1282) 

• 70 messages 



• Civil-4|)2 (1167) 

• 6 bytes/message 



• Rushes-iOO/day 

System &ipetvisor 




• 70 messages 

• 6 bytes/message 




SSRC 




! • 70 messages 

• 6 bytes/message 

1 

NA 

MAIL-IOOZ (1290) 

READ-1002 (1290) 

14 

NA 

MFILH-IOOZ (2449) 

Total-2450 



Manual-Few* 

1 VAlN)-262 (645) 
ENC-74^ (1805) 

1 

NA 

Telephone Ifcequests- 

DEDS 



80/day 

• to messages 



• flO messttges 

• 20 bytes/message 



• 100 bytes/aessage 

1 Syst^'m Supervisor 



System Supi^rvisOT 

m 10 messages 



• 10 wesstiges 

• 70 bytes/message 



• 100 bytiDs/aessage 

SSRC 



SSRC 

• to messages 



• 10 aesssges 

• 100 byttcs/message 

^ • 70 bytes/aess^e 

I’-' 

!■;( 



ji 


HTBF 

(RRS) 


Krxx 

(HRS) 


X 

ATAIL-^ 

ABILIT5T 









Table A-1, Operational Component 


t 


O Q 

*ira S3 

w;=sa 

waft* 

c^- 

^ r** 

Ip t/> 

E! 

**-rt «— 


opoiAtional component 


READ 


SAR 


SEAR 


VDENT-A 


DESCRIPTION 


[Quality Control Check, Read, 
and Annotate 


Semi-Automatic Fingerprint 


Search Review 


Verify Data Entry-Cards 


SERVICE 


RATE^ 


120 

Docunents 


150 


30 


DNK 


NO, UNITS 


a 


15 


50 


PER 

WORK 

CELL 


NA 


NA 


NA 


PCN APR.- 


AFRS-100 ( 
CSORT-few 
TSS (Querj 

• 30 mess 

• 6 bytes 
TSS (Minut 

• 30 mess 

• 500 byt 

Total-1972 
VDEKT-A-48: 
AFRS-511 C 
SAR-IX (30: 
System Sup< 

• ^972 me: 

• bytes 

(A'^) 

DEDS ' 

• 1972 mes 

• 40 bytes 
tAvg) 


DENT-A-(2254 

5SRC 

• 2254 mess 

• 20 bytes/ 
System Super 

• 2254 mess 

• 20 bytes/i 
DEDS 

• 2254 mess; 

• 20 byrcs/i 




•ummary CCont ’d) 



INTERFACES^ 


JJPur'^ 


OUTPUT^ 


HXBF” 

<NRS> 


htir' 

CHRS) 


X 

AVAIE-- 

ABILlTr 


Total-1290 
ENDOC-822 (1060} 

I AUT0C0R-ManuaI-X8Z (230) 

SEAR-IOOZ (30) 

TSS 

• 30 message 

• 20 bytes/message 
System Sopervisor 

• 30 messages 

• 10 bytes/message | 


Total-1972 
AUT0a»-24Z (468) 

I CLAS^35-3Z (00) 

cLoc-jz ies) 

MFIlii-152 C?^) 

Archival File-42Z (838) 
Civil File-122 (238) 
Hanual-0.32 (6) 

DEDS j 

• 3944 messages 

• 11 bytes/message 
CAvg) 

System Supervisor 
a 3944 messages 
. • II bytes/message 
CAvg) 

! SSRC 

• 1839 messages 

• 15 bytes/message 
(4vg) 

.TSS 

. • 1844 messages 
- a 15 bytes/message 
(Avg) 

Total-2254 
CIw\SS-»-I52 (335) 
CLCK-382 (852) 

SEAR-417 (939) 

Civil File-6Z (128) 

DEDS (Search Parameters) 

• 2254 messages 

• 70 bytes/message 
(Avg) 


Inc* 


Inc- 


7000 


2.0 


99.97 


4000 


2.0 


99.95 







Table A-1, Operational Component Summary (ContM) 


OPERATIONAL CCWPONEKT 


BESGRimON 


I PER 

ITOTAL WORK 

1 CELL 


INTERFACES* 


IKpDT^ 

OCTPn^ 


HTBF^ KTIR*^ AVA 

(HRS) <imS) ASH 


I 


I Verify Data &jtry-Itocuments 


30 

Doctinencs 


DENT-B-^IOOZ (1220) 
SSRG 

• 1220 messages 

• 20 Lytes/acssage 
Systea Supervisor 

• 1220 messages 

• 20 byces/aessage 
OEDS 

• 1220 messages 

• 20 bytes/aessage 


DEDS (Arrest Data) 

• 2254 messages 

• 90 bytes/aessage 
(Avg) 

Systen Supervisor 
(Search ParaaKters) 

• 2254 messages 

• 70 hytes/message 
System Supervisor 
(Arrest Data) 

• 2254 messages 

• 90 bytes/message 
SSRG(Search Parameters) 

• 2254 messages 

• 70 bytes/message 
SSRC (Arrest Data) 

• 2254 messages 

• 90 bysres/message 
TSS 

• 2254 message 

• 70 bytes/message 

Total-1220 
ACI0C0R-5X (60> 

I Hanual-95X (1160> 

DEDS (Search Parametets) 
• 1220 messages 
• 70 bytes/message 
DECS (Update Data) 

I • 1220 messages 
I *90 bytes/aK^ssage 
I System Supervisor 
I (Search Parameters) 

i « 1220 messages 
• 70 bytes/message 
System Supervisor 
I (Cpdate Data) 

I • 1229 messages 
I • $0 bytes/message 
I SSRG(3earch Parameters) 
I • 1220 messages 
I *70 bvtes/mcssage 
I SSRC.<rpdate Data) 

I • 1220 leessages 
I • 90 bytes/message 





Table A-1. Operational Component Summary (Continued) 





APPENDIX B 

OPERATIONAL COMPONENT STATIC CAPytCITY SUMMARY 


Table B-1 reflects a aunnary of the operational component static 
capacity analysis. The data contained for each component includes: 


Acronym ; 

An abbreviation used in the system to identify an opera- 
tional component. Table B-l is in, acronym order. 


Description : 

Complete description of each component can be found in 
Appendix G. 

Total Required Capability : 

The number of units to be processed per hour by the 
component! based on work load guidelines. 

Service Rate : 

The processing rate of a single unit in the component. 
Number of Units Proposed ; 

Number of work stations proposed by Rockwell for the 
component. If the component is in a work cell, the x 
figure represents the total number of units, and the y 
figure represents the number in each of the 15 work cells. 


Productivity of N Units ; 

Number of units proposed imi.^tiplied by the service rate. 

X Space capacity of N Units at lOOX Availability equals: 

Service Rate x N Units (Availability) - Required Capability x 100 

Required Capability 

% Space Capacity of K-l Units at lOOX availability equals; 

Service Rate x N-I Units (Availability) - Required Capability x 100 

' Required Capability 

Calculated X Availability: 

The probability that the equipment will perform its intended 
function when required. 


B-l 






X Space capacity of K Units at calculated avallabilityt 

Service Rate x N Units (Availability) ~ Required Capability x 10 0 
Required Capability 



B-2 


ORIGINAL PA.GE IS 
OF POOR QUALITY 


Table B-1. Operational Cos^onent Static Capacity Stumnary 


Operational Cociponent 

Total 

Re(patrcd 

Capability 

CCards/Hc3^> 

Service 
Rate 
Per Oolt 
Per Uour 

Nuniber 
of Units 
Proposed fS) 

Productivity 
of U Units 
Per Spur 

X Spare Capacity® 
of lt Units at 

Z Sparc Capacity® 
pi Units at 

Calculated 

X 

X Spare Capacity* 1 
ef 18 tbtits at 1 
Calculated | 

Acronya 

Desctlptioci 

1002 Availability 

im Avpiminty 

Availability b 

Availability i 

APRS 

Autonacic Fingerprint 
Reader Systea 

1,033 

210® 

5 

1,050 

1.7 

-18.7 

95.00® 

98.82^ 

-3.4 

0.4 



1*033 

315® 

5 

1.575 

52.5 

21.9 

95.00® 

98.82* 

44.8 [ 

50.6 



1,033 

les"* 

5 

825 

-20.1 

-36.1 

95.00® 

53.82* 

-24.1 

-21.1 



1,033 

250® 

5 

1,250 

21.0 

-3.2 

95.005 

98.82 

14.9 

19.6 



1,033 

195^ 

5 

975 

-5.6 

-24.5 

95 . 00 “ 

98.B2 

-10.3 

-6.7 



1,033 

29i® 

5 

1.465 

41.8 

13.5 

95 . 00 ' 

90.82^ 

34.7 

40.1 



1,033 . 

225" 

5 

1.125 

8.9 

-12.9 

55.005 

98.82^ 

3.5 

7.6 



1,033 

338® 

5 

1,690 

63.6 

30.9 

95.005 

98.8r 

55.4 

61.7 

AirrocoR 

Aotoaated Correspondence 

2,410 

Pieces 

100 

25- ] 

(Kamiall 

2,500 

3.7 

-0.4 


— 

AliXORESP 

j 

Autonated Response 
Generation 

2,000 

Output 

Documents 

Inc* 

26 ^ 






BU) 

Blocking Out I?er 
Work Cell) 

4» 

50 

30/2* 

100* 

108,3* 

4.2* 

— 

M 

I 

1 

CLASS-A 

0 - 

ClassIfication~A 

|^i?r Work ilelt J 0 , 

75 

10 

120 /a* 

80* 

6.7* 

-6.7* 

99.97 1 

6.6* 1 

CLASS-B 

Classlflcaclon-B 
)Per Work Ceil) 

2& 

10 

A5/3* 

30* 

15.4* 

-23.1* 

89.97 1 

15.4* 1 

OJVSS-C 

Class£ficatloa-€ 

■ W5 


20 

8 

Oianual) 

160 

lO.O 

-3.4 

I ; 


4 


»Per Work Cell 

“Porconr Sporo capacity . x li , ,00 

• llegacfve flgsress I^iiicate Insufficient Units tn Handle Ke^iV«»l Capalyltitj- 

• Q.Ot S|kire CapaUUltj^ indicates Hatgtnal Feasii»nity 

Does not Inclwde interfacing coeimter ^ubts^stem avaUabrii lt|r data. 

• Does not include trans|K»rcation systen avanabltlty tiaca. 

^Rockwell Data 


Jfl- Study Data 




frevintis Service Rate liw nMtH'4 SO SU?Sfc^ cw JtivLwtlS \%1H> 

Kodif teat inns 


' Fll C«lde*lee; t IS 

F ^ I 

**d data <»n iliis tine is %m .* V,trfc ti ll 

^^$|Si:re Hat'b Im? 5SR tiSH^i’rary ,mi rimmitts r*.r 1 

Himr. I 
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Table B-1. Operational Component Static Capacity Summary (Continued) 


Operatiooal Coapoceat 

Total 

ke<|ttired 

Service 

Rate 

Per Ifalt 
P er Hoar 

Koaber 
of Daits 
proposed 0J> 

Prodnctivitp 
of H Oaits 
Per Bonr 

2 Spare Capacity* 
of H Deits at 

Spsre Capacity* 
«f Ditits at 

Caltalated 

2 

X J^are C^city^ 
ef M Onlts at 
. Calcalated 

AcxoayM 

Description 

(Caids/Bonr) 

1002 Availability 

100? AvailBlillity 

AvailaklUty 6 

Availability 

cidt 

Classiflcatioa CbeclE: 
per Work CclXl 

m 

4S 

45/3* 

135* 

53.4* 

2.2* 

99.97 

53,4* 

CSORT 

Cefiterli&e Sort 


90 

12 

1.080 

4.5 

*-4.2 

- 

*- 

BATESTP 

Date Staap. <^omt aad 

1^635 

1,635 

CHanoall 

1,635 

0.0 

*-100.0 



DEKI-A 

Data Bntiy-Cards 
CPcr Vork CePJ 

ISO 

30 

90/6* 

1K»* 

20.0* 

0.0* 

99.95 

19.9* 

0EKT-B 

Data Potty-Docuaents 

i.220 

30 

42 

1,260 

3.3 

0.8 

99.95 

3.2 

EBC 

Pocode Inpot Data^-Cardls 
per Vork CelU 

150 

40 

60/4* 

CMaauall 

160* 1 

6.7* 

-20.0* 



EKCOOC 

Encode Input Data- 
Docuaenta 

- ^ 1.220 

35 

35 

Oia^aual) 

1.225 

0.4 

-2,5 


" 

HiCIC 

Encode Cbeck'-Cards 
per Vork Celll 

ISO 

80 

30/2 

160* ? 

6.7* 

-46.7* 

— 

— 

EHDOCK 

Bxcode Check'^Docoaenta 

1763 

75 

17 

{Macmall 

1,275 

4,5 

-1.6 



TtAB 

FiXs Processing/CoBposer 

3.000 

Card 

InagOs 

3.070 

2 

6.140 

104.7 

2.3 

99.50 

181,5 

HJCMD 

Flla 10|^ Into Consoles 

96 

Ficke 

96 

1 

(Kanoal) 

96 

0,0 

-109.0 


«, 

aci 

Imagr* Co«^arls<Ki 
Identifleatioo 

1»233 

laages 

72 

19 

1,368 

10.9 

5.1 

99,72 

10.6 

ICV 

laage Omparison 
VerPlcation 

863 

laages 

75 

13 

975 

15.7 

6.8 

99.71 

15.3 

jttn. 

OpCA Hail and Sort 

63,677 

Pleces/Day 

720 

6 

(Hanoal) 

48.600 
Per Day 

11.3 H 

U 

-7.3 

*** 

■** 

^vn 

Xaage Capture Hicroillne 

2,469. 

3.037*" 

600 

(.',hzz:600 

6** 

3,000 

3,600 

22.5 ! 

18*5 

-2.9 

-1.2 

99-96 

99,96 

22.% 

18.5 

?qf 

Process Control Vuaber 
Applioatlon-Cards 

2.449 

2.000 

2 

4.000 jj 

63.3 : 

-18.3 

99.06^ 

9«,l2r 

61,8 

iMI.t 


Process Control tk»ber 
Appltcation-Docmenta 

i^Sso 

Docuaeats 

1.300 

1 

CHaanal) 

1,300 

i' 

0.0 

-100.0 





















Table B-1. Operational Component Static Capacity SuBDary (Continued) 


t^ersciooal Owpc»aeot 


Acroa;ym 


I>escrlptioa 

Quality 0»ttol Oieclc 
Outline Quecy 


WEAD Quality Control Che<:lc» 

Head* ami Amiotatc; 

SAR i Sc^MrrAutoauiclc Finger^ 

. print Iteader 

SEAR Seard) Xevlnr 

VDEJrr-A Verify Data Entry-Carda 

{Fer Vnrk CeUJ» 

VDBrr-B Verify Data Entty-l 

Doct»eat 

VASD Vend Out of Syatesa 

Work Cell 


Total Senrice 

Rei)nired Rate Kiaaber 

Capability per Oclt Halts 

(Cazda/Bottr) Per Boor Proposed tS) 


Calls/Day 

1,290 


2,3«2 
Cine, 128 
frew 
SEMI) 


of K QtiitS 


Z spare Capacity* 
«f ^ Halt# at 
100^ AvailakiUty 

X Sp«re Ca^pacity* ! 
of 11^1 Baits at : 
10QZ AaalUkility 

2.S 

j 

-4.5 

AB.S 

-I-OO.O 

2,3 

-7.0 j 

16.7 

OwO 

W.l 

«.s 

^.0* 

0,0ft 

3.3 ■ 

o.t 

55.0 

24.0 

0,0 

-6.5 


CalcOated 


Z Spmr^ Capacity^ 
S Zmlt» at 
CaXtaiated 





APPENDIX C 




BSTIHATED OPERATIONAL COHPONENT/COMPUTER SUBSYSTEH 
DATA TRANSFER REQUIREMENTS 


D«ta contained in Table C-1 reflect! an eiti«ate by JPL of the 
relative ecope of the hourly Maaagt volimei and related record lizei 
that are propoaed to be tranaferred between operational conponenta and 
the coBiputer aubayateaia. 




SCiSfUVm TO StSTEH I i line 
scpmisim IKTEllFACES JibOO l.t«a 


|4 

*00 iM!i4 
























APPENDIX D 


DATA SOURCES 

The rates used in the evaluation process were from various 
sources with varying degrees of consistency end rationale. Where a 
derivation of the rate was provided by Eockwell, this is so noted. 
Estiisates by jPL baaed on Rockwell date or arrived at from other than 
Rockwell sources -^e also noted. If no remark is made, the rationale 
or derivation for the data stated in the reference was not speci- 
fically identified. 

Data sources are listed in this Appendix for: 

(1) Nuisber of Work Stations 

(2) Service Rates 

(3) Eervv ^ Rate Distribution Function 

,, (4) Card /Document VbUttnes and Routing Distribution 

(5) Maintenance 

(6) Data Transfer Message Volumes and Size 
A. Nusfeer of Work Stations 


Acronym 

Description 

Source 



APRS 

Automated Fingerprint Reader System 

Reference 

23 

, Page 4 

AUTOCOR 

Automated Correspondence 

Reference 

7, 

Page 6 

AUTORESP 

Automated Response Generation 

Reference 

6, 

Page 16 

BLO 

Blocking Out 

Reference 

8, 

Page 26 

CLASS-A 

Classification-A 

Reference 

8, 

Page 26 

CLASS-B 

Cl ass i f i c ation-B 

Reference 

8, 

Page 26 

CLASS-C 

Class i fic at ion-C 

Reference 

1, 

Page 4-7 

CLCK 

Classification Check 

Reference 

8, 

Page 26 

CSORT 

Centerline Sort 

Reference 

7, 

Page 6 

DATE STP 

Date Stamp, Count and Log 

Reference 

7, 

Page 6 

DENT-A 

Data Entry-Cards 

Reference 

8, 

Page 26 

DENT-B 

Data Entry-Documents 

Reference 

7, 

Page 6 

ENC 

Encode Input Data-Cards 

Reference 

8, 

Page 26 

ENCDOC 

Encode Input Data-Documents 

Reference 

7, 

Page 6 

ENCK 

Encode Check-Cards 

Reference 

8, 

Page 26 

ENDOCK 

Encode Check-Documents 

Reference 

7, 

Page 6 

FLAB 

Film Processing/Composer 

Reference 

2, 

Page 5J 

FLOAD 

Film Load Into Consoles 

Reference 

1, 

Page 6-41 

ICI 

Image Comparison Identification 

Reference 

7, 

Page 6 

ICV 

Image Comparison Verification 

Reference 

7, 

Page 6 

MAIL 

Open Mail and Sort 

Reference 

7, 

Page 6 

MFLIM 

Image Capture Microfilm 

Reference 

7, 

Page 6 

PCN 

Process Control Number Appl-Cards 

Reference 

7, 

Page 6 

PCN APPL 

Process Control Number Appl -Documents 

Reference 

7, 

Page 6 

QC 

Quality Control Check 

Reference 

7, 

Page 6 

QUERY 

"On-Line Query 

Reference 

7, 

Page 6 

READ 1 

Quality Control Check, Read, and 
Annotate 

Reference 

7, 

Page 6 


0-1 



Acronym 


Description 

// 

SAR 


Semi-Autoiqatic Fingerprint Reader 


SEAR 


Search Review 


VDENT-A 


Verify Data Entry-Cards 


VDENT-B 


Verify Data Entry-Documents 


WAND 


Wand Out of System 


— 


Work cell 

V, 


B. Service 

)) 

Rate 


Acronym 


Description 


APRS 

O 

Automated Fingerprint Reader System 

' ? D 

AUTOCOR 


// 

/,/ 

Automated Correspondence 


AUTORESP 


Automated Response Generation 

1 

■| 

■1 

'■ 1 
i 

BLO 


•Blocking Out 

f,< 

1 
■ I 

i 

\% 

■| ' ■ 

CLASS-A 


Class if ication-A 

■if 

;i 

§ 

i? 

;e 

■\ 

CLASS-B 


Classification-B 

i 

1 ■ 

CLASSnp 


Classif ication-C 

1 

CLCK 


Classification Check 

i 

I 

CSORT 


Centerline Sort 


DATE BTP 


Date Stamp, Count and^log 


Source 

Reference 1, Page 6-12 
Rockwell experience 
Reference 7, Page 6 
Reference 8, Page 26 
Reference 7, Page 6 
Reference 7, Page 6 
Reference 8, Page 27 


Source 


JPL Studies and Refer- 
ence 6, page 12 - See 
Appendix F 

Reference 8, Page 13 - 
engineering estimate 

Reference 7, Page 6 

Reference 8, Page 13 - 
Test results of 75 
cards/hour derated 
to 50 C/H to allow 
designation of 
possible illegibles. 
Based on measurements 
from similar 
functions* 

Reference 8, Page 13 - 
FBi Standard for full 
Henry Classification 

Reference 8, P^ge 13 - 
FBI Standard for full 
Henry Classification 

Reference 1, Page 4-7 

Reference 8, Page 13 - 
FBI-supplied estimate 
of current performance 

Reference 5, Page 9 - 
Time and motion 
estimate and file 
conversion 

Reference 7 , Page 6 


D-2 






Acronym 

Description 


Source 

DENT-A 

Data Entry~Cards 


Reference 8, Page 13 - 
Based on 4600 key- 
strokes/hour and 
160 character/card 

DENT-B 

Data Entry-Documents 


Reference 8, Page 13 - 
Based on 4800 key- 
strokes/hour and 
160 character/card 

EMC 

Encode Input Date-Cards 


Reference 8, Page 13 - 
FBI-supplied estimate 
based on AIDS I 
performance 

ENCDOC 

Encode Input Data-Documents 


Reference 5, Page 10 - 




Estimated 

ENCK 

Encode Check-Cards 


' Reference 8, Page 13 - 
FBI-8uppli?Jd estimate 
based on AIDS I 
performance 

ENDOCK 

Encode Check-Documents 


Reference 8, Page 13 - 
Estimated 

FLAB 

Film Processing/Composer 


Reference 6, Page 8 

FLOAD 

Film Load Into Consoles 


Reference 7, Page 6 

ICl 

Image Comparison Identification v 

I . } 


Conflicting data was 
presented in Refer- 
ence 2, Page 86 

ICV 

i 

Image Comparison Verification > 


(Studies), Refer- 
ence 5, Page 10 
(which references Ref- 

“i, 

i7 


erence 2, Page 86) , 
and Reference 7> 

Page 6. The service 


U 


rate stated in Rfifer- 
ence 7, Page 6 was 
selected as being a 
reasonable compromise 
between the conflict- 
ing data* 

MAIL 

Open Mail and Sort 


Reference 8, Page 13 - 
Engineering estimate 

MFLIM 

Image Capture Microfilm 


Reference 5, Page 10 - 
Model M600W/PCII Mods. 


■ 


D-3 




Acronym 

PCN 

PCN APPL 

qc 

QUERY 

PAD 

SAR 


SEAR 

VDENT-A 


VDENT-B 


WAND 


Deicription 

Process Control Number Appl-Cerds 

process Control Number Appl “Documents 
Quality Control Check 
On“Line Query 


Quality Control Check, Read, and 
Annotate 

Semi-Automatic fingerprint Reader 


Search Review 


Verify Data Entry-Cardls 


Verify Data Entry-Documents 


Q 


Wand Out of System 


Work Cell 


Source 

Reference 7, Page 13 - 
Derated from design 
rating 

1 

Reference 8, Page 13 - 
FBI-supplied estimate 

ii 

Reference 8, Page 13 - 
FBI-supplied estimate 

Reference 5, Page 10 - 
AIDS II experience 

Referetvce 5, Page 10 - 
Estimated 

Reference 8, Page 13 - 
Rockwell experience 
on Rockwell's terminal 
used in latent print 
processing 

Reference 8, Page 13 - 
Engineering estimate 

Reference 8, 'Page 13 - 
Based on 4800 key- 
strokes/hour and 
160 characters/docu- 
ment I 

J 

Reference 8, Page 13 - 
Based on 4800 key- 
strokes /hour and 
160 characters /docu- 
ment 

Reference 8, Page 13- 
Engineering estimate 

JPL estimate based on 
de(]ailed analysis of' 
card routing distri- 
biiition shown in 
Figure E-1 


D-4 













I 




C. Service Rate Distribution Function 


\ 


In all cases where the service rate distribution 
used, it was obtained from Reference 8, Page 13. 

D. Card/Document Volumes and Routing Distribution 

function is 

Acronym 

Description 

Source 

APRS 

Automated Fingerprint Reader System 

Reference 

AUTOCOR 

Automated Correspondence 

Reference 

AUTORESP 

Automated Response Generation 

Reference 

BLO 

Blocking Out 

Reference 

CLASS-A 

Class if ication-A 

Reference 

CLASS-B 

Class if ication-B 

Reference 

CLASS-C 

Classification-C 

Reference 

CLCK 

Classification Check 

Reference 

CSORT 

Centerline Sort 

Reference 

DATE STP 

Date Stamp, Count and Log 

Reference 

DENT-A 

Data Entry-Cards 

Reference 

DENT-B 

Data Entry-Documents 

Reference 

ENC 

Encode Input Data-Cards 

Reference 

ENCDOC 

Encode Input Data-Documents 

Reference 

ENCK 

‘ Encode Check-Cards 

Reference 

ENDOCK 

Encode Check-Dpcuments 

Reference 

FLAB 

Film Process ing/Comppser 

\ Reference 



i 

Reference 

FLOAD 

Film Load Into Consoles 

Reference 

ICI 

Image Comparison Identification 

Reference 

ICV 

Image Comparison Verification 

Reference 

MAIL 

open Ma^ and Sort 

Reference 

MFLIM 

Image Capture Microfilm 

Reference 

PCN 

Process Control Number Appl-Cards 

Reference 



See Note i 

PCN APPL 

Process Control Number Appl -Documents 

Reference 

QC 

Quality Control Check 

Reference 

QUERY 

On-Line Query 

Reference 

READ 

Quality Control Check, Read, and 

Reference 


Annotate 


SAR 

Semi-Automatic Fingerprint Reader 

Reference 

SEAR 

Search Review 

Reference 

VDENT-A 

Verify Data Entry-Cards 

Reference 

VDENT-B 

Verify Data Entry-Documents 

Reference 

WAND 

Wand Out of System 

Reference 


7 

7 

7 

7 

7 

7 

7 

7 

7 

7 

and 


Page 6 
Page 6 
Page 6 
Page 6 
Page 6 
Page 6 
page 4“'7 
Page 6 
Page 6 
Page 6 
Page 6 
Page 6 
Page 6 
Page 6 
page 6 
Page 6 
Page 6 


Page 16 
Page 6 
Page 6 
Page 6 
Page 6 
Page 6 
Page 6 


Page 6 
Page 6 
Page 6 
Page 6 


page 6 
Page 6 
Page 6 
Page 6 
Page 6 


NOTE As - There is a conflict between Reference 7, Page 6, Reference 8, Page 9 
and Reference 10, Page 9> concerning the mix of input cards. Data 
from References 7 and 8 was used as it was the most consistent’. 
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Maintenance 


Mean-Time-Between-Failurea and Mean-Time-to-Repair data waa not 
identified by specific source or related to a specific operational 
component , 


The evaluation team used its best judgment based on the generic 
data presented to relate the data to the operational component. 


Mean-Time-to-Respond was stated in Reference 5, Page 47^ ,%o be 
1.0 hour. In determining Mean-Time-to’-Restore, this hour was added to 
all Mean-Time-tO'^Repair data. 


Acronym 


Description 


Source 


APRS 

AUTORESP 

CLASS-A 

CLASS-B 

CLCK 

DENT-A 

DENT-B 

FLAB 


Id 

lev 

MFLIM 

PCN 

QUERY 

SAR 

SEAR 

VDENT-A 

VDENT-B 

WAND 


Automated Fingerprint Reader System 
Automated Response Generation 
' Classification-A 

Classification-B - 

Classification Check 
Data Entry-Cards 
Data Entry-Documents 
Film Processing/Composer 


Image Comparison Identification 
Image Comparison Verification 
Image Capture Microfilm 
Process Control Number Appl-Cards 
On-Line Query 

Semi-Automatic Fingerprint Reader 
Search Review 
Verify Data Entry-Cards 
Verify Data Entry-Documents 
Wand Out of System 


JPL Study - Appendix H 
Reference 24, Page 8 
Reference 24, Page 8 
Reference 24, Page 8 
Reference 24, Page 8 
Reference 1 , Page 6-85 
Reference 24, Page 8 
Reference 1, Page 6-87 
- Configured for on- 
line backup 

Reference 24, Page 6-8 
Reference 24, Page 6-8 
Reference 24, Page 8 
JPL Study - Appendix H 
Reference 24, Page 8 

Reference 24, Page 8 
Reference 1, Page 6-82 
Reference 24, Page 8 
Reference 24, Page 8 


F. Data Transfer Message Volumes and Size 

The subsystem interfaces between the operational components and 
the various subsystems were derived from Reference 6, page 16, and the 
various subsystem descriptions found in References 1, 6 and 7. 

The message volumes between the Operational components and the 
computer subsystems were derived from the source indicated in Para- 
graph E above, Card/Document Volumes and Routing Distribution. 

When the Operational component transmitted only PCN status 
accounting information, to the System Supervisor, a Value of 
10 bytes/message was assumed. 
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other 

Acrony 

APRS 

AUTORESP 

OLASS-A 

CIASS-B 

CLCK 

DENT-A 

DENT-B 

FLAB 

FLOAD 

ICI 

tcv 

MFLIM 

PCN 

QUERY 

DENT 

SAR 


SEAR 


VDENT-A 

VDENT-B 


■esiage aises were obtained from the following sourcea; 


Deacription 


Source 


Autonated Fingerprint Reader Syaten 
Autoaiated Reaponae Generation 

Claaa if ication-A 
Claaaification-B 
Claaaification Check 
Data Entry-Card a 
Data Entry-Docuaienta 

Film Proceaaipng/Compoaer 
Film Load Inl'^o Conaolea 

Image Compariaon Identification 
Image Compariaon Verification 
Image Capture Microfilm 

Proceaa Control Number Appl-Cards 
On-Line Query 

Semi-Automatic Fingerprint Reader 


Search Review 


Verify Data Entry-Carda 
Verify Data Entry-Documents 


Reference 6, Page 26-17 
Reference 7, Page 6 and 
JPL eatimatea 
Reference 6, Page 21 
Reference 6, Page 21 
Reference 6, Page 21 
Reference 8| Page 13 ^ 

Reference 5 , Page 10 and 
Refe^rence 8^ Page 13 
Reference 6, Page 19 
Reference 1, Page 6-41 
and, JPL extrapolation 
Reference 2, Page 106 
Reference 2f Page 106 
Reference 6f Page 19 and 
Reference 2, Page 106 
Reference 6, Page 19 
JPL estimate based on 
DENT and VDENT data 
JPL estimates based on 
the number of fingers to 
'^be encoded (2) and 
250/bytes finger 
JPL estimates based on 
the data requirements of 
the various status 
conditions of the cards 
and extrapolations from 
previously documented 
processing information 
Reference 8, Page 13 
Reference 5| Page 10 and 
Reference 8| Page 13 
Reference 6f Page 20 


WAND 


Wand Out of System 


APPENDIX E 


special fingerprint classification terminal 


The fingerprint classification teminal requires nore study and 
testing before a comitment to its use is nade* There are two basic 
design alternatives for this station. The first combines the classi*- 
fication process with the data entry process ^ while the second breaks 
out the data entry as a separate position. Appendix E addresses the 
human factors for these alternativesi as well as the design of the 
proposed terminal itself. This decision will be based on the classi- 
fication work station processes described in Referenoe 1. The human 
factors will be identified and analyzed, and both advantages and 
disadvantages of the alternatives will be addressed. 

If it is decided that the Special Classification Terminal is to 
be implemented, wholly or partially, there are concerns with the 
keyboard design regarding data entry errors that it might promote. 


A. CLASSIFICATION/DATA ENTRY FUNCTIONS 

1. Task Analysis „ 

The fingerprint classification process consists of the following 
individual tasks: 

Fingerprint analysis and classification - Specific charac- 
teristics of each print on the fingerprint card are 
translated into an alphanumeric code. The throughput 
summary (Reference 1) indicates an expected 10 documents 
per hour. After removing the time required for data 
entry, this translates into an average of one fingerprint 
card every 3 minutea and 30 seconds. 

Classification data entry - The classification codes are 
entered into a data entry terminal for storage in the 
system,. Assuming that each classification code is 2 
characters (for a total of 20 characters), and using the 
card keystroke model (Reference 37), the time required to 
enter the FCN and classification codes is estimated at 30 
seconds. 

Classification data entry verification - The codes entered 
into the data entry terminal are verified on the CRT 
screen be fotfj transmittiiig it to the System Supervisor. 

2. Work Station Configuristion Alternatives 

h 

The work station alternatives are the one-position work station 
and two-postion work station. In the one-position work station, the 


( 1 ) 


( 2 ) 


f - 

(3) 
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technician classifies each fingerprint and keys the classifications 
into a data entry terminal. The two-position work station separates 
the classification and data entry tasks. 

Following are comments on pertinent issuesi 

Cloauga “ Closure is the technical term for the degree of 
satisfaction felt by an individual after completing a 
task. A task with high closure is one in which the 
completion is clear and well identified. A task with low 
closure is one in which the completion of the task is not 
Clear. The classification task probably has a medium 
level of closure. The closure for the classification task 
is the completion of the classification codes. The 
closure for the data entry is the completion of the input 
keystrokes. Closure for the data entry verification is 
wlien the visual data check is complete and the card 
complete key is hit. We can expect Che closure for the 
data entry tasks to be lower Chan for the classification 
task. It is not clear that the combined Casks of classi- 
fication and data entry have any higher level of closure 
than the individual Casks. 

(2) Compatibility - The issue here is the compatibility 
between the classification task and the data entry task. 
The two tasks are essentially independent. Although they 
are not totally incoropar/ible, there is very little simi- 
larity between the tasks, and no reason to combine the two 
for compatibility. 

(3) Error Detecting - Combining the classification and data 

entry tasks increases the error detecting capability of 
the work station. For data verification tasks, the 
operator/technician can relate the entered data back to 
the original source, the fingerprint, making it easier to 
recognize an erroneous data entry. For the tWo-position 
work station, the data entry and verification tasks are 
separated from the original data in the classification 
task. Therefore, the data entry operator can only relate 
back to the intermediate (handwritten) data. The data 
entry operator did not participate in the original classi- 
fication code generation, and therefore does not have a 
feeling for the validity of the entered data. i* 

The advantages of increased error detection capability is 
reduced in the one-position work station, since the 
classification verification work station is expected to 
detect data entry errors as well as classification 
errors. It is conceivable that the increased error 
detection of the one-position work station would allow a 
reduction in the number of classification verification 
stations, but it is not likely to be significant. 
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Skitli - The claesification technician is trained in the 
skill of classifying finger)!;^rints using a particular 
method. The skills required to enter the data into a 
terminal are quite different. There is no advantage to 
combining these tasks in terms of skill compatibility. 
There is merit in separating the task assignments » in 
order to capitalise on skill specialisation in maximising 
throughput. 

( 5 ) Learning - Because the classification and data entry tasks 
are different, the learning (or training) process is 
complicated^ With separated positions (tyo**position work 
stations), the technician is not burdened with having to 
learn the data entry tasks at the same time as he is 
learning the classification task. This may not be signi- 
ficant, as the data entry task would probably be fairly 
easy for a technician. In any event, separating the tasks 
would reduce the learning load on the technician. 

(6) Job Variety - The two-position work station does provide a, 
modicum of job variety for the classification technician. 
Data entry and verification tasks require different 
activities. It is not clear whether this would be 
regarded as a welcome relief or as an added burden. 

Direct measurement would be required to determine how 
classification technicians would react to this issue. 

Most likely, the lower skill level of the data entry task 
would provide little in the way of satisfactory job 
variety. The separated (two-position) work station would 
provide another type of data entry task, which might 
provide more job variety for the operator. 

(7) Economics - There may be a cost savings in a two-position 
work station configuration. In the two-position configiiir- 
ation, the classification task becomes completely manual 
in nature, and all mechanical and electronic equipment can 
be eliminated. The data entry task can be accomplished 
with fewer terminals, although additional personnel may he 
required. The economic aspects require additional study, 
as the concerns for data entry following the CLASS-A 
function are different than those following CLASS-B and 
CLCK. 


3. Advantages/Disadvantages of Configuration Alternatives 

The one-position work iitation has an advantage in increased 
error detection for the data entry task. It may have a disadvantage, 
however, in the economics and training areas. No advantage or disad- 
vantage is seen with closure, job variety, or job skills issues. 


ORIGINAL PAGE If 
OF POOR QUAUTY 


The two‘”po»icion work eCarion may have advantagea from an 
economic and braining atandpoint. There are aome advanbagea in bhe 
areas of skill level and joh varieby* The only disadvanbage bo this 
configurabion is in error debecbion; which is mibigated by bhe clasai- 
ficabion verificabion funcbion (eapacbed bo uncover daba enbiy errors 
as well as classificabion errors). 


Cl' 

4. Reconmendations 

The bwo-posibion clasBificabion work stabion, in which classi- 
ficabion and daba enbry basks ace separabed) is sbrongly recoaimended 
for further analysis and study from both the human and economic 
Standpoints. 


B. SPECIAL CLASSIFICATION KEYBOARD 

The decision to use a special keyboard design (i.e.| differing 
radically from a conventional typewriter or QWERTY keyboard ) , should 
be based on an analysis of the specific tasks bo be accomplished and 
the characteristics of the special keyboard. The special keyboard 
must offer significant advantages over a conventional keyboard format 
to warrant its use. General task requirements include the manual 
identification of specific fingerprint characterisbics, converting 
them to a code, entering the code on the fingerprint card and entering 
the code into the computer system. Functionally, it is assumed that 
the major amount of time will be spent in encoding the fingerprints. 
Some time is required to enter the codes through the keyboard, and 
more time is required to verify the codes on the display. The princi- 
pal areas of operator attention are the fingerptint cards with indivi- 
dual prints, the keyboard, and the data display on the terminal. 

The encoding process is beyond the scope of this critique; it is 
primarily a customer skill. The verification process should be 
straightforward, since the display format is well suited to that 
applidation. It provides compatibility between the encoded display 
and the original fingerprint card, reducing any adjustment required by 
the operator when going from the display to the fingerprints. 


1, Data Entry Methodology 

It would be advantageous if the data entry procedure were an 
over learned process (e.g., touch-typing). If data entry is an bver“ 
learned process, the operator has only two centers of attention: the 

fingerprint and the coded display. If it is not an overlearned process 
the operator has three centers of attention. In addition to the finger 
print and coded display, he must also think about the keyboard. 
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Ov«rl«frnln| it i proccii that: requlrei craining and praccice. 
Eaja of learning dependa on the coaipatibiliCy becween the operatr^r and 
the proceaa (Reffrenco 32). The aiaount of training and practice 
required depend upon the following co^>atlblMty factorai iwichanical> 
conceptual and apatiali Hechanlcal coiapaCiblllty concerna the ability 
of an operator to phyaically accoaipliah the taak. Conceptual compati** 
bility la when the proceaa feela natural to the operator (thia laay be 
due to ione inherent qualityi cultural background^ or a previoualy 
learned experience). Sp?,tiai coeipatibility concerna the aimilarlty of 
phyaical arrangement between different elementa of a proceaa. 


2. Special terminal Keyboard Layout 

It ia intereating to compare the propoaed apeclal keyboard with 
the conventional QWERTY keyl^pard in the context of the previoualy 
outlined taak acenario. Since 1975i aociety haa had a great deal of 
experience with QWERTY keyboarda. Inveatigationa have indicated thatj 
although it may not be the optimuni it ia aufficiently cloae. The 
conventional keyboard fita the line of the fingeraj and the keya are 
comfortably apaced. With the touch ayatem, each finger haa to move 
only two rowa upf one row down> and one key to each aide (each finger 
ia reaponaible for a limited number of keya). With fahift key, the 
entire ASCII character aet ia available. Thia large character aet 
allowa flexibility in the man/computer interface dialogue, which can 
accommodate future expantiona or ehanges in the basic process. With 
operators trained in the touch-typing ays tern, the QWERTY keyboard has 
conceptual compatibility} they are familiar with it. Even operatora 
who have not had typing training and who use the hunt-and-peck ayatem 
find the QWERTY keyboard familiar. Although the QWERTY keyboard does 
not have spatial compatibility with the fingerprint classification 
process, this is not important aince, in an overlearned ayatem, the 
physical configuration of the keyboard does not require attention. 

What is important is that the man/computer dialogue design should be 
conceptually compatible with the fingerprint classification process. 
The QWERTY keyboard requires two hands, which could be a disadvantage 
in some situations. 

We have had no experience in using the special keyboard, so we 
do not know whether is is better suited to this specific function or 
not. However, we can analyse it as we did the QWERTY keyboard. The 
physical arrangement of the special keyboard is not mechanically 
compatible with the human hand, and the keys appear to be very close 
together. The keyboard does not provide a reference key for hand 
placement to support touch typing. It appears that the special 
keyboard also requires two hands. Hand placement for touch-typing on 
the special keyboard is closer than is required on the QWERTY keyboard. 

Reference 1 states chat the special keyboard complements the 
classification function by providing a finger-block display layout, 
similar to that of the fingerprint card, and special-purpose keys to 
input preferred finger classifications and references. The display is 
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both conc«ptu«I1y «nd tpatially coapatible with the iingerprlnt card, 
but thla doea not apply to the keyboard # The keyboard layout ia not 
related to the card layout. The key labela are conceptually coapati- 
ble with the fingerprint claaaification proceea (good for a hunt-and- 
pcck typing ayatem), but thia ia inmaterial for an over learned or 
touch-typing ayaten. For 'a touch-typing ayatem, the key poaition ia 
the important iaaue. The apecial-function keya are appropriate when a 
limited number of functiona are to be aelected. Nominally, the limit 
ia on the order of aeven functiona. Thia aeema to be the largest 
number of functiona that the general population can easily diatinguiah 
(Reference 33). The propoaed apecial keyboard contains more than 
aeven apecial function keya, and these arc mixed with transaction keya 
such as "Card Complete,” "Clear Card,” etc., which increasea the 
difficulty of using the keyboard. 

The numerical keyboard ia a telephone-style format. This may 
create some serious compatibility problems. The telephone format 
places the number 1 in the upper left of the numeric keyboard with 
2 and 3 to the right, and 4 through 9 below. The moat-used alternate 
numeric keyboard configuration is the calculator format, where 1 is 
placed on l'*he lower left, 2 and 3 on the right, and the remaining 
numbers above. The specific difficulty with the telephone-style 
nuBieric keyboard ia that is is not compatible with the calculator- 
style keyboard. Even though touch-tone telephones employing the 
telephone-style keyboard are becoming more common, calculators are 
also widely used (especially in business). Also, the data entry 
function is conceptually eoppatible with the calculator function 
(rather than the telephone-number-selection function). Standard 
keyboards on available computer terminals usually use the calculator 
style for the numeric keyboard. Having two different styles increases 
the difficulty of rotating operators within work stations for training 
and upgrading of personnel. 

The location of the '‘Enter” key creates another conceptual 
cosipstibility problem. This key signifies the completion of a data 
element. On a typewriter, the same basic function is a carriage 
return. On calculators, it is and All of these keys 

are to the right of the data keys. The more normal keyboard charac- 
teristic is to use the little finger of the right hand for this 
function. The special keyboard places the "Enter” key below and to 
the left of the numeric keyboard. This implies that the first or 
second index finger would be used, which is clearly incompaCible with 
other data-entry activities. Again, this might create transaction 
problems in rotating operators within work stations, and training 
problems for new or upgraded operators. 

Frequency of errors is another issue that needs addressing. 

When a data-entry system incorporates a significant possibility of an 
operator error, the system performance is reduced. If the operator 
fedls that he must be very careful to avoid making an error, he must 
then work at a slower, morg deliberate pace. If the operator inadver- 
tently hits the "Clear Card" key while expecting to hit one of the 
others in the normal data-entry process, his previous work will be 
cleared. This is quite frustrating, and^^recovery is time-consuming. 


E-6 


The same conment at>plies to the ''Sign Off* key, which is located next 
to the "9" key. A slight mistake, and the work station is 
disconnected from the computet. 

If a special keyboati is used, it is suggested that the keys 
providing different functions be physically separated. The data entry 
keys shovtld be located together for a smooth, key-stroke flow. The 
error-recovery keys (*'Clear Card," "Clear Entry," etc.) should be 
physically separated from the data-entry keys and the system-function 
keys ("Log On" and "Sign Off") should be together but separated from 
the other keys. The *'Card Complete" key should be separated from the 
other keys. Its function is to terminate the individual card trans- 
action, and it is initiated after the data has been entered and 
verified. This expanded configuration would localize functions for 
better comprehension and use, reduce errors due to misplaced key- 
scrokes, and reduce the distraction of keys demanding the operator's 
attentidh around the data-entry keys, making the keyboard easier to 
use. 

A back space key should be included for error recovery. Clear- 
ing the entire entry to a clear a character errd't i® s drastic action 
which beeixnes especially frustrating when an error is near the end of 
the data item. 

In conelusion, it Is net clear that a data-entry terminal is 
appropriate for this application. If one is used, the keyboard design 
should be improved to increase performance and reduce error rates. 



ORIGINAL PASE IS 
OF POOR QUALITY 
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APPENDIX F 


AUTOMATIC FINGERPRINT READER SYSTEM (APRS) SERVICE RATE 


A. 


SERVICE RATE USED FOR EVALUATION 


Various service or throughput rate capabilities for the Auto- 
natic Fingerprint Reader System (APRS) function have been stated. 
Reference 7, Page 6 indicates a value of 210 cards/hour. The FBI 
Guidelines to Rockwell (Reference Page 13) indicate a range of 210 
+ 15 cards/hour (i.e., between 195 and 225 cards/hour). JPL studies 
indicate a throughput capacity range of from 107 to 176 cards/hour 
with a weighted average of 165 cards/hour (Reference 19). This rate 
equates rather well to the overall fingerprint file conversion effort 
average rate of 18,000 cards/day (Reference 35). Using 165 cards/hour 
as a basic service rate, and assuming the successful implemention of a 
50% APRS productivity increase as a result of the modification pro- 
posed by Rockwell (Reference 6), a service rate of 250 cards/hour was 
used in evaluation of the APRS component. Appendix B reflects the 
details of the static analysis on the APRS function for the varying 
service rates. 


The results of the JPL study (discussed in Paragraph B) were 
based on data gathered from actual FBI worklogs processed by all five 
AFRSs for the file conversion effort (i.e,, reading all fingerprint 
cards on file with subject date of birth 1929 and later, and storing 
the minutiae data for use in Technical Search when AIDS III is imple- 
mented), This conversion required reading several different versions 
of the fingerprint card used over the years. Many of the cards pro- 
cessed were dog-eared, frayed and required mending to process them 
through the AFRSs. 


Rockwell has stated (Reference 6, Page 12) that, for a modest 
additional investment, the minutiae detection processor can be inclu- 
ded in the hardware, increasing the throughput by 50%. According to 
Rockwell, this modification has already been made on some of their 
equipment, and a 50% improvement was seen. This has not yet been 
demonstrated in a production environment to the JPL evaluation team. 
Estimated costs for such a modification are included in the AIDS III 
capital cost estimates. 


The use of a service rate of 250 cards/hour provides a 21.0% 
spare capacity with all five AFRSs in operation. With only four AFRSs 
operating, a -3.2% capacity is experienced. Results of the sifflulatioh 
model show that the 250 cards/hour rate does not adversely impact the 
ability of the system to process cards in a given period of time at 
the 1993 workload, with a 50/50 (criminal vs civil) mix. 


The ongoing operability of the AFRSs as they ^ige could become a 
problem. From an operability viewpoint, the primary concern in this 
function is cards jamning due to their poor physical condition. The 
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card dejaiming procedure described on page 1~218 of the Calspan manual 
(Reference 20) is complex and time-consuming. The procedure has been 
substantially modified in the Rockwell-designed production AFRSs 
(Reference 22, Page 4-2), Malfunctioning of the card hopper is 
usually caused by an accumulation of paper dust, which can be avoided 
by routine cleaning. The quality and newness of the inquiry finger- 
print cards should greatly reduce this problem. 


B, MEASUREMENT OF APRS SERVICE RATE 

To measure the APRS production rate, statistics were taken from 
the Automation and Research (A&R) Finder Room production data log 
(Reference 19). The sample size used was 53 work periods distributed 
among day, night and midnight shifts. The duration of each shift was 
7.5 hours. Samples were picked at random from the months of Septem- 
ber, October, November and December 1979. 

The criteria used to reject a sample were; 

(1) When an APRS was not operational because of lack of work-. 

(2) When no report was generated for a specific APRS. 

(3) When an APRS was used for pilot test activity. 

The statistics generated were weighted by sample size to reduce 
the degree of bias. 

The computation of the mean production rate yielded 165 finger- 
print cards/AFRS/hr. 

The calculations using the September 1979 production data log 
follow: 



Sample Size 

Fingerprints/hr 

% Rejects 

System 1 

29 

176 

6,1 

System 2 

25 

156 

5.3 

System 3 

25 

169 

3.3 

System 4 

26 

173 

5.2 

System 5 

20 

107 

9.5 


P-2 










Net weighted average: 


_ 29 X 176 + 25 + 156 25 x 169 +^Z6 x 173 + 20 x 107 

" ) 125 

_ 5104 + 3900 + 4225 + 4493 + 2140 
125 

■ “159 fingerprtnts/APS/hr 


Weighted rejects: 

29 X 6.1 + 25 X 5.3 + 25 x 3.3 + 26 x ).5 

125 


176.9 •»• 132.5 + 82.5 + 135.2 109 

125 


The October, November and December logs give the total number of 
fingerprint cards attempted per shift for the five AFRSs. 

A 5% reject level was used to obtain the net fingerprint cards 
processed. 

Calculations from the October, November and December production 
data logs give the following: 



1s.') 

U' 


Total fingerprint cards attempted 
Sample size n 
5025 


Mean = 


28 


Rejects 

Net fingerprint cards read: 
179 ( 1-0.05) 


5025 

28 

179 

5% 


“ 170 fingerprints/AFRS/hr 


Combining the September samples with the October, November and 
December samples yields the following: 


25 X 159 + 28 X 170 
53 


165 fingerprints/AFRS/hr 


APPENDIX G 


SYSTEM COMPONENT DESCRIPTIONS 


A. OPERATIONAl, COMPONENTS (FUNCTIONS) 

1. AUTOCOR (Automated Correspondence) 

At this functioni all information about a subject (no identi- 
fication notification» rap sheet, wants, etc.) to be sent to the 
contributor is accumulated (with fingerprint card, documents, etc, if 
they are to be returned) and placed into an envelope* addressed, and 
submitted to the mail room. Responses prepared in AUTORESP on fan- 
folded computer paper are burst prior to placing in the envelope. No 
identifications that are to be returned are hand stamped. Incomplete 
or illegible fingerprint cards are also returned to the Contributor 
from this function. 


2. AUTORESP (Automated Response Generation) 

This function generates computer-printed responses that will be 
returned to the contributor. It will, where possible, group responses 
to the same contributor. The results of the searches in AIDS III and 
one address label for each envelope (containing multiple responses to 
a contributor) will be printed on high-speed line printers. These 
responses are thon sent to Automated Correspondence (AUTOCOR). The 
high-speed printers will also print the name index cards to update the 
Card Index name files (the manual system). 

3. APRS (Automatic Fingerprint Reader System) 

The Automatic Fingerprint Reader System (AFRS), consisting Of a 
card handler, a scanner, a control computer and a data output pro- 
cessor, performs the function of taking the fingerprint image on the 
fingerprint card and converting it to machine-readable format (Figure 
G-1). 

The fingerprint card is transported from the input hopper via a 
motor-driven belt and positioned under the scanner. The cards are 
registered to read the fingerprint image and process control number. 
The positioning and card movement are computer-controlled. At each 
position, a pair of fingerprints is scanned. After all pairs are 
scanned, the card is moved to the output hopper or, if a complete scan 
was not made, to a reject hopper. 

The main components of the scanner of the AFRS provide the light 
source and the image sensing functions. The light source is a CRT 
that is computer controlled in its X and Y axes to illuminate the scan 
pattern. Within the control computer, the following functions are 
performed: preprocessing scanner movement and illumination control, 

postediting and encoding of the minutiae detected in the fingerprint 
images. 
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Figure G 1. Automatic Fingerprint Reader System 









The APRS Data Output Processor (DOP) processes the input minu- 
tiae information through the registration algorithm. This includes 
finding the core of the print image, determining the X-Y axes of and 
referenced to that image, transplanting the X, Y and 0 minutiae 
information to the image orientation and reducing the image area to 
0.75 in X 0.75 in from the original area of 1.5 in x 1.5 in, This 
information then constitutes the output of the DOP, and is the regis- 
tered set of minutiae sent to the matcher. The matcher does the 
actual comparison of the subject fingerprint data with data in the 
technical file. 


4. BLO (Blocking-Out) 

All cards received by BI.0 are criminal card? without an FBI 
number. A high level fingerprint classification is performed at this 
function. Any prints that are illegible are fls>gged so that the 
arrest data is not entered at the data entry function (DENT-A and 
VDENT-A) for the initial subject search. 


5. CLASS-A (Classif ication-A) 

The classification process includes determining the NCIC finger- 
print classification, writing the classification on the card and enter- 
ing it into the system via a special purpose terminal. This activity 
does a full NCIC fingerprint classification on all civil, military, 
and Coast Guard cards. Reference to the preferred classification is 
also entered on the card. 


6. CLASS-B (Classification-B) 

This activity receives all of the criminal cards for which no 
candidates were found by the automated subject search or, if found, 
were not identifications. The full NCIC fingerprint classification is 
determined and written On the card. It is then keyed into the AIDS 
III system with the use of a special purpose terminal. Reference to 

the preferred classification is also entered on the card. 

7. CLASS-C (Class ification-C) 

This function classifies all alien registration and personnel 
identification cards. The classification is made and entered on the 
card. The classification performed here is not as detailed as re- 
quired for criminal searching. The cards are then forwarded to the 

civil file for filing. 

8. CLCK (Classification Check) 

At this station, the NCIC fingerprint classification verification 
is made and the cards are sorted into legible and illegible categories. 
The classification check for civil cards is less extensive than for 
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criminal cards. A special purpose teminal is used in this function 
in the verification of the data previously entered into the sysii.em. 


9. CSORT (Centerline Sort) 

The fingerprint cards are inspected to determine the approximate 
centerline of the inked fingerprintst A template is used to manually 
determine the centerline of the fingerprints. The cards are placed 
iniio one of the ten channels going to the Automatic Fingerprint Reader 
System (APRS), depending upon the centerline group to which they 
belong. Cards for which no centerline can be determined or which are 
of low print quality are routed directly to the Semi-Automatic Reader 
System (SAR). 


10. DATE STP (Date Stamp) 

This manual process handles only alien registration and personal 
identic ioation cards. The cards are date-stamped and counted. Once a 
day statistics are logged to the computer. The cards are then classi- 
fied and forwarded to the civil files. There is no process control 
number application, subject search, or technical search required for 
these cards. 


11. DENT-A (Data Entry-Cerds) 

All data from fingerprint cards that is required for the auto- 
mated subject search and to update the Computerized Criminal Name and 
Record (CCNR) files is entered by a data entry operator. 

Data is entered from the cards to formatted screens selected by 
the operators. Data is stored in the frOnt-end computer and will be 
verified by the data-entry verification (VDENT-A) operation. In the 
DENT-A function, there is no interaction with the host computer. For 
a detailed description of this function and its relationship to 
VDENT-A, see Section IX, Paragraph A, Automated Subject Search Per for- 
inAnc0 • \c — 


12. DENT-B (Data Entry-Documents) 

Within the operation, document information from wants, flai^hes, 
expungements, dispositions, etc. is entered into the system. The data 
enteredjj includes information required to generate a subject search for 
identix4cation purposes, and the appropriate data to be added/deleted/ 
revised on the individual record (i.e., arrest information, sentencing, 
etc.). The data is key-entered and stored in a front-end processor 
(FEP) to await verification (VDENT-'B). The process in this component 
is similar to DENT-A, 




G-4 



13. ENC (Encode Input Data-Cards) 

In this function) the data input formats are checked and the 
criminal arrest data are encoded. The operator checks the charges on 
t-he subiect fingerprint card against a list of standard charges) sel- 
ects the most appropriate representation and enters that code number 
on the card. 


14, ENCDOC (Encode Input Data-Documenta) 

All dispositions and miscellaneous documents which generate 
inquiries or updates against the inaster file are coded at this func 
tion. Many documents require that the coding be on forms which 
accompany the source document. Examples of items coded include 
offenseS) date of birth, race, sex, etc. 


15. ENCK (Encode Check-CardB) 

This function is an independent validation of the charge codes 
selected by the ENC operation. The operator compares the charge code 
on the fingerprint card against a set of standard charges to ensure 
that the proper code has been selected. The cards are then sorted and 
routed to Che appropriate function downstream. 

16. ENDOCK (Encode Cheok-Doouments) 

The encoding performed in function ENCDOC is reviewed and 
verified at this operation. 


17, FLAB (Film Processing and Fiche Duplication) 

TTie Film Processing Lab receives l6mm cartridge film containing 
1000 card images/cartridges from the Image Capture (MFLIM) stations. 

It develops the film, then produces and duplicates ultramicrofiche at 
a lOX reduction (containing 2000 card images/fiche) . 

18. FLOAD (Film Load) 

This function is not a work station per se, but an activity. The 
duplicated microficha are distributed to each of the Image Compar- 
ison (ICI) and Verification (ICV) work stations for insertion in the 
appropriate location in the microfiche carousels. 


19. ICI (Image Comparison Identification) 

The function of the Image Comparison Identification component is 
to display fingerprint images for the examiners to compare subject 
prints against candidates selected as a result of either a subject 


search or a technical (fingerprint) search, the examiner must dieter'' 
mine whether a positive fingerprint match has been made. 

The search inquiries are assigned to stations based on the 
inquiry NCIC fingerprint classification of the particular candyates. 
Each station contains microfiche fingerprint images of both the 
inquiry subject and the candidate(s) selected from the fingerprint 
microfiche master file. The inquiry and the candidate fingerprint 
images are automatically displayed side-by-side, A keyboard accepts 
comparison decisions and control commands from the examiner. A 
separate text display prompts the operator and displays system status. 

The microfiche fingerprint card images at each work station are 
stored in carousel-type storage and retrieval mechanism. Bach station 
contains 500 fiche, and each fiche contains 2000 imageS) giving a 
total capacity of 2 >000,000 images per station. 


20. lev (Image Comparison Verification) 

The Image Comparison Verification function verifies the identi- 
fication (if any) made in the Image Comparison Identification (ICI) 
function. The process and work station facility is similar to the ICI 
function. ICV has a smaller workload than ICI because it only veri- 
fies the ICI identifications. 


21. MAIL (Mail Room) 

Mail is receved daily from the post office. The input t oluine is 
highly variable (from 17 cubic feet to 68 cubic feet per day). The 
mail is opened and sorted into three basic categories: 

1. Fingerprint cards (both civil and criminal). ip 

2. Alien registration and personal identification fingerprint 
cards. 

3. Dispositions, flashes, wants, expungements, etc. 

It then is routed to the next appropriate function. 

22. MFILM (image Capture Microfilm) 

At the Image Capture function, fingerprint cards are microfilmed 
at a 6.3X reduction. The associated PCN are read with an optical 
character reader (OCR) and associated with the image in the Trans- 
action Record. 1000 card images are produced on each 16mm microfilm 
Cartridge. 
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23. PCN (Proc«88 Control Number AppUeation-CardB) 

A proc688 control number (PCN), which is e unlquei machine^ 
readable number^ is printed on each inquiry fingerprint card as it 
enters the system. The PCN is a 12-digit number structured as 
YYPDDSSSSSCC where: 

YY ■ digits of year 

ODD •> Julian date r 

SSSS8 ■ Five digit sequence nuiiiber 

CC “ check digits 


As each PCN is generated, a Master Transaction Record (MTR) is 
established. The MTR is the means by which the AIDS III System can 
track the detailed status of each inquiry card from the time it enters 
the system until it is disposed of at the end of the processing cycle. 
The MTR consists of a series of fields which provide the means of de- 
fining the detailed status of each card. 


24. PCN APPl( (Process Control Number Application-Documents) 

All documents processed by the AIDS III system require a unique 
process control number (PCN) which is stamped on the document (or an 
attached routing form) via a "Bates” type stamp machine. 


25. QC (Quality Check) 

At this manual function, the fingerprint cards are checked for 
completeness of information. Any incomplete or inappropriate cards 
are returned to the contributor. Several hand stamping operations are 
used to highlight special conditions. 


26. QUERY (On-Une Query) , 

W ■ 

To accommodate special requests from contributors and FBI 
offices received over the telephone, via wires or from special corre- 
spondence, one CRT work station is designated for on-line interro- 
gation of the AIDS III files. Most requests will be satisfied by 
reading information from the CRT screen at the work station. Some 
requests will require data to be printed out from individual file 
records on the Computerized Criminal Name and Record (CCNR) files and 
sent to the requestor. Interfacing with the manual system for finger- 
print cards, jackets, or photographs may be required. 


27, PJAD (Quality Control, Check, Read and Annotate-I acumenta) 

At thia point, all documenta and final dispoaitiona are mixed 
together. The diapoaitiona are separated and tent on to the next 
operation for coding. All remaining documenta are given a quality 
control check to ensure that information required for data entry is 
correct, Documenta found to be incomplete are sent back to the 
contributor or to the manual ays tern, 


28, SAR (^emi-Automatic Reader) 

Cards that have one or more fingerprints rejected by the Auto- 
matic Fingerprint Reader System (APRS) require manual minutiae en- 
coding using the SAR. Fingerprints that cannot be manually encoded 
are designated as rejects and returned to the contributor. 

To encode the minutiae data manually, the PCN is keyed into the 
system, and the finger number to be encoded is displayed on the screen 
That particular fingerprint is then placed under a high resolution 
closed circuit television (one finger at a time). The print is 
registered (squared-up and centered), and a trackball used to position 
a cursor on the CRT screen. The point is registered with a button and 
the cursor is then moved 1/4 to 1/2 in. (usually along a line of a 
fingerprint and showing up as a darker line), then registered a second 
time. This creates a short line, Using the center, x and y coordi- 
nates, an angle is calculated. Once a sufficient number of minutiae 
are encoded (usually 40 to 100 Individual points) the data is regis- 
tered and then sorted on Y descending order. This data is then 
transferred to the candidate minutiae file to complete the information 
necessary for an automated technical (fingerprint) search. 


29. SEAR (Search Review) 

In those cases where an identification has been made and veri- 
fied (ICI and ICV), this function authorizes the update of the arrest 
data to the files. Where no positive identification has been made, 
this function reviews the parameters used in the search. The search 
parameters and statistics are displayed for the inquiry and if, in the 
judgement of the SEAR operator, changes to one or more of these 
parameters could bias the search process such that a new candidate or 
candidates may be located, the operator may cause a new search to 
begin at any one of several steps. For new criminal file additions, 
the SEAR operator assigns a unique FBI number to the card, updates the 
Transaction Record and routes the card back to be microfilmed (MFLIM) 
for permanent addition to the file. 

The search review operator also controls the secondary card 
routing (i.e., non-identifications are routed to the proper function 
to continue their flow through the system) . Inquiry into the Master 
Transaction Record provides the operator with the necessary informa- 
tion to route the card. 


original Pf-ff 

OF POOR QUALITY 


G-8 


30. 


VDENT-A (Verify Entry-Carde) 


The VDENT-’A function verifies the fingerprint card date that has 
been entered by the data entry operator (DEHT**A). Hie data parameters 
required for the automated subject search are entered first. Wlien 
this data (60**60 characters) has been verified^ the automated subject 
search is initiated. While the search proceeds, the VDENT-A operator 
enters the remaining arrest data (average of 80-100 characters). The 
search process is discussed in Section IX, Paragraph A, Automated 
Subject Search Performance. 

Based on the results of the subject search, a message is dis- 
played instructing the VDENT-A operator where to route the fingerprint 
card. Xf there are one or more candidlates, the card is sent to 
Search Review (SEAR); if there are no candidates, but it is a military 
card, it goes to the Civil file. Non-candidate criminal cards are 
routed to be classified in more detail (CLASS-B), and non-candidate 
civil cards ore routed to have a classification check (CLCK) prior to 
being submitted for an automated technical (fingerprint) search. The 
search and arrest data, along with the search results, are stored in 
the Transaction Record (TR) file to await final disposition. 


31. VDENT-3 (Verify Data Entry-Documents) 

At this component, document information entered in data entry 
(DENT-B) is verified. After the descriptive data required for the 
subject is entered, the automated subject search is initiated. As the 
search is being conducted, the operator enters the remaining descrip- 
tivG data for verification. The VDENT-B operator is notified by the 
system if an identification has been made, and routes the document 
accordingly. 


32. WAND (Wand Out of System) 

This function receives from quality check (QC) any rejects or 
incomplete fingerprint cards that are to be removed from the AIDS III 
system. A card may be rejected by QC for the following reasons. 

(1) Only four fingers were fingerprinted. 

(2) Information is missing, 

(3) Search not required by law for the applicant card, 

(4) A non-AIDS FBI number* 

(5) civil file name search required. 

The PCN number is read by an optical character recognition (OCR) 
wand, and the appropriate reason for removal of the card from the 
system is entered into the system via a keyboard terminal. The cards 
are then routed to either the manual system or automated correspon- 
dence (AOTOCOR) . 
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B. COMPUTER SUBSYSTEMS 

1, DEDS CDntfl Entry and Display Subaystam) 

(1) Dnocytption ; The Data Entry and Display Subayaten con- 
slat& of a aeries of free-standing coroputera used to 
enter, validate, and buffer data prior to burst trans- 
mission to the System $upervisor« Information can also be 
returned and displayed on some of the DEDS equipment 
(i.e,, the results of a subject search are returned to a 
VDBNT operator with routing instructions)# The Data Entry 
and Display Subsystems support the basic data entry, 
Verification and inquiry functions. 


(2) Configuration ; The SEAR, WAND, and Classification func- 
HoniiGLASS A and B and CLCK) are all configured with 
their own front-end processors (FEPs), One FEP is planned 
to handle the SEAR and WAND functions, with a second used 
as backup. Three sets of FEPs are planned to handle the 
classification and classification check functions (CtASS A 
and B, and CLCK). Each set consists of a primary and a 
backup FEP. The entry and verification (DENT-A and B, and 
VDENT-A and B) portion of the DEDS consists of 9 separate 
FEPs (Four Phase Equipment), each hooked directly to the 
System Supervisor. There is no backup for this equipment 
(that is, there is uo auxiliary FEP to switch to in the 
event of a failure), 


(3) Interfaces ; The main components of DEDS and its associ- 
aTted actions and interactions with the System Supervisor 
are as follows: 

a . Data Entry and Verification 

Enter data for subject search from card and verify. 

Send verified data to System Supervisor for subject 
search. 

Enter, verify, and transmit arrest data for criminal 
cards. 

Enter, verify and transmit file update information 
for documents. 

Receive card routing in forma, tion. 

Respons e fay Sys tem Supervisor 

Update Master Transaction Record (MTR). 

Update Transaction Record (TR) with subject search 
information. 
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Initiate subject search. 

Update MTR with search results, 

send card routing information to VDENT*-A or B. 

Format Image Comparison Request (ICRQ) and send to 
Image Comparison Subsystem (ICS). 

Receive and send additional criminal card data to 
Subject Search and Report Generation Subsystem 
(SSRG) for TR update. 

Forward file update requests and information to SSRG 
document. 

bir Classification 

Enter and verify full NGIC fingerprint classification. 
Response by System Supervisor 
Update HTR. 

Send classification to Technical Search Subsystems 
(TSS) for TR update. 

Remove illegibles from the system. 

c. Wand Out of System 

Transmit process control number and reason data on 
those cards being removed from the AIDS III system. 

Response by System Supervisor 
Update MTR. 

Close for rejected cards. 

d. Search Review 

Request status information by Process Control Number. 
Change search parameters and initiate a new search. 
Remove cards from system. 

Route cards according to search status. 

. \ ^ . . . 
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Assign new FBI number for criminal non- 
identif ic 4 \tlons (non-idents) . 


e. Response by System Supervisor 

Send search status information from SSRG. 

Close MTR for cards being removed from system. 

Update MTR, TR, and search paramters for a new search. 

Authorize updates or additions to the Computerized 
Criminal Name and Record (CCNR) files and the Minutiae 
Master File (MMF) as appropriate. 

Authorize a response generation. 


2. ICS (Image Comparison Subsystem) 

(1) Description ; The function of this subsystem is to compare current 
subject prints against candidate prints (both sets of prints are 
on microfiche and are displayed automatically). 

As a result of a subject or technical (fingerprint) search, a list 
of one or more candidates may be generated. The image comparison 
functions (ICI and ICV) compare the fingerprints on the current 
subject against the fingerprints of the candidates on the list. A 
simple ident or non-ident response for each candidate is given. 

For rush requests, the FBI number can be entered at an image 
comparison terminal and the fingerprint location will be found. 

The microfiched print is then displayed and compared with the 
inquiry hard copy fingerpirint card. No response to the System 
Supervisor is entered. \ ; 

(2) Configuration ; For the ICS, all of the image comparison consoles 
are hooked into a single front-end processor (FEP). One FEP is 
expected to handle the processing requirements of the subsystem, 
although a second FEP for backup is provided. These two FEPs are 
joined by switch able controllers. 

(3) Interfaces ; The main components of the ICS and its associated 
interactions with the System Supezvisor are as follows; 

a. Image Comparison Consoles 

Request fiche location by FBI number (for rushes). 




Receive image comparison request and send microfiche 
retrieval Information to the microfiche file hard- 
ware . 


Transmit image comparison results. 

b. Response by System Supervisor 

Form and send image comparison requests using PCN 
and FBI number with fiche locations. 


Receive image comparison results. 


Update MXR with search results. 


3. PICS (Process Control Number and Image Capture Subsystem) 

(1) Description ; The PICS subsystem is primarily a message handling 

function. T'<e information coVlected, Process Control Number 
(PCN) and microfilm loaction are buffered and then sent to the 
System Supervisor. For each fingerprint card that enters the 
AIDS Illf a PCN is assigned. This number is used to track the 
card and access any pertinent information. The fingerprint 
cards are microfilmed and then microfiched with the appropriate 
location information appended to the Transaction Record (IR). 


(2) Configuration ; In the PICS subsystem, the PCN machines, micro- 
film cameras and the microfiche composers are all hooked into a 
single front-end processor (PEP). One FBP is planned to handle 
the processing requirements of the subsystem, but a second FEP 
is provided for backup. These two are jointed by switchable 
controllers. The facility sensors are tied directly to the 
System Supervisor and do not interface with thfi PIC subsystem 
FEPs. '■ 


(3) Interfaces ; The main components of the PICS subsystem and its 
associated actions and interactions with the System Supervisor 
are as follows; 

a. PCN Machines 

i^ransmit last valid PCNs. 

Transmit invalid PCNs. 

Actions by System Supervisor 

Create MTR and TR for each PCN. 
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b. 


Image Capture Camerns 


Transmit PCN, frame no., type (permanent, 
current, temporary), and toll no. 

Response by System Supervisor 

Update MTR. 

Update TR to show location on microfilm. 


c. Microfiche Composer 

Transmit PCN, fiche no., type, frame no. 
Response by System Supervisor 
Update MTR. 

Update TR to show location on microfiche. 

Based on fingerprint classification, calculate 
which ICI and ICV consoles the permanent 
microfiche should be routed to. 


SS (System Supervisor) 

Description ; The System Supervisor is comprised of three main 
functions: system monitoring and control, system simulation and 

management report generation. The latter two are discussed 
separately in paragraph 4. The main function discussed here is 
that of system control and monitoring. The handling and routing 
of information is the major effort involved in this portion of 
the System Supervisor. 

Each of the subsystems, and their associated components, trans- 
mit information to the System Supervisor. p4rt of the infor- 
mation is kept by the System Supervisor while other parts of the 
information are routed to other subsystems. Some of the infor- 
mation requires manipulation and a response to one or more 
subsystems. Myriad combinations of data routing can occur, 
making the overall interaction very complex. 

The main functions handled by the System Supervisor are; 

Monitors, controls, and interacts with all of the related 
subsystems and with the card allocator system. 

Maintains responsibility for card routing and process 
control. 


Acts as link between all subsystems. 

Controls the Management Reports and System Simulator. 

Creates^ updates and closes Master Transaction Record 
(MTR). 

Purges all references to a PCN for a closed MTR. 

Creates, updates, purges a Transaction Record (TR). 

Controls and authorizes response generation. 

Controls file updates and authorizes updates of specific 
files (CCNR, MMF, etc.). 

Polls various systems for information. 

Maintains Equipment Status files. ' 

In addition, each subsystem, computer and component will have 
monitoring devices connected in some undefined fashion. These 
devices can range from very simple (an empty hopper indicator) 
to very complex (switchover to a backup unit due to impending 
failure). A brief list of capabilities and/or functions is as 
follows: 

Equipment Status - i.e., sensors linking a component and 
its subsystem computer - may relate operational status, 
queue sizes, etc. 

Operating Limits - i.e., overload or underload condition. 

Measurement Data - inputs to Count workloads, queue sizes, 
response times, etc. for both a subsystem and/or indivi- 
dual station (especially as relates to deflectors and 
allocators) . 

Diagnostics for failures, including: 

Automatic switchover to backup functions. 

On-line fault isolation diagnostics. 

Fault isolation for non-standard devices. 

Configuration : For the System Supervisor, one CPU is planned to 

handle the processing requirements, with a second planned for 
backup. The two CPUs are joined by switch able controllers. The 
system management terminals, management reporting facilities, 
and program development facilities are also tied into the System 
Supervisor CPUs. 


(3) Interfaces ; Interfaces with each of the subsystems as detailed 

in the description of the respective subsystem, 

(4) Management Report Generation and System Simultion (MRGSS) Task 

a. De script ion t The MRGSS task is part of the System Super- 
visor . Di f f eren t files (hardware status, PCNs, manpower, 
etc.) are accessed and the information contained within 
these files is used to create Management Reports. There 
is no definition as to the content or frequency of these 
reports, therefore, no specific rates or information 
transferrals can be implied. The real-time interactive 
nature of monitoring suggests a very detailed set of 
informational files. This set of files is proposed to 
provide a mechanism for data collections, report genera- 
tion and system performance monitoring. 

A software simulator which models the system operation is 
proposed for predicting volumes, queues, etc., given 
variations in card mixtures, missing components, or other 
^namic portions of the system. This simulation is 
inclusive down to the component level (i.e. , the effect of 
removing a single component or station from operation can 
be evaluated). The simulator package will have access to 
many of the same files utilized by the management report 
task. This feature of the System Supervisor is only 
generally addressed at the highest conceptual level. 

b» Configuration ; This task is a part of the System Super- 
visor and the combined configuration is addressed in the 
configuration discussion, above. 

c. Interface ; 

Management Report System Simulator Task 

Real-time interactive monitoring of stations 
Real-time monitoring of hardware availability 
Receive inputs from System Supervisor reflecting; 
Hardware status 
Manpower configuration 
Queue lengths 

Productivity of individual stations 
Card mix and routing 
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Accumulate data and generating reporta 

Interactive System Simulator 

Responses by System Supervisor 

Send status of any part of the system 

Send rates for an individual station or a set of 
stations on demand 

Send diagnostic data and keep the information files 
updated 


(SSRG) (Subject Search and Response Generation Subsystem) 

(l) De script ion ; The System Supervisor formulates a search 
request and sends it to the SSRG subsystem. After a 
search of the Computerized Criminal Name (CCN) file, a 
Jist of candidates (if any) is returned to System Super- 
visor, which routes the name of a candidate(s) to the data 
entry verify operator (VDENT-A and B) with a response from 
search review (SEAR). 

A positive ident from the Image Comparison verification 
function (ICV) results in an authorization to update the 
CCNR files. Responses are generated, and those that 
require return of the original cards are matched with 
their responses and sent to the mail room. 

The SSRG subsystem also maintains the information about 
the inquiry subject in the Transaction Record (TR). This 
information is compiled and then used in the updating or 
creating of records in the Computerized Criminal Name and 
Record (CCNR) files. 


(2) Configuration ; The SSRG subsystem, consists of response 
generation line printers, and an estimated 3 or 4 Subject 
Search Modules (SSMs). The SSMs are envisioned to be 
computers with any 3 of the 4 able to handle the load. 

The extra is a backup in case of failure or some other 
Qrm of system degradation. 

The SSRG architecture calls for two CPUs. Under normal 
operations, the two are to operate in a load sharing mode 
(i.e. , the prime CPU controls the search and file update 
processes while the secondary CPU handles the respohse 
generation process). The CCNR files are shared between 
the two CPUs. 

If one of the CPUs is down, the prime function subject 
search will presumably be executed in the up machine, with 
response generation occurring as time allows. 
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(3 ) Interfaces; 


a. SSRG Comput er 

Receive Subject Search Request 

Return list of candidates (if any) 

Receive arrest record for criminal cards 

Store data for probable file update in 
the TR 

Store data with new FBI number if 
non*-ident in the TR 

Update CCNR files from data in the TR when 
authorized by SEAR 

Generate responses 

b. Responses by the System Supervisor 

Format Subject Search request and send to SSRG 

Update MIR with search results 

Obtain microfiche location for Subject Search 
Candidate list 

Send card routing information to the VDENT 
function 

Send Response Generation Authorizations 
Send CCNR Update Authorizations 


TSS (Technical Search Subsystem) 

(1) Description ; This subsystem attempts to match the inquiry 
subject fingerprints with a set of Minutiae Master File 
(MMF) fingerprints. Additional data similar to the 
subject search data plus the NCIC fingerprint classifi- 
cation is used in the technical search process. This 
subsystem automatically reads the fingerprints, extracts 
minutiae data, and seeks a possible match. The Automatic 
Fingerprint Reader System (AFRS) and Semi-Automatic 
Readers (SAR) are used to "read” the fingerprint and 
calculate minitiae data. The minutiae data are compared 
against the MMF data (by NCIC classification bins) in the 
Search Processor Modules (SPM) to obtain the most likely 
candidate. 
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(2) Configuration : For the TSS, all of the Search Proceaaor Modules 

(SPM - estimated at 5 to 15)r all 5 of the APRS, and the FEPs 
for the SARs are hooked directly to the subsystem computers. 

One CPU is planned to handle the load, but a second CPU is 
proposed as a backup. These two are joined by svitchable 
controllers. 


(3) Interfaces ; The main components of the TSS and the 

associated interactions with the System Supervisor are as 
follows: 

e. TSS Computers 

Receive full NCIC fingerprint classificaticn (plus 
references) and search data 

Transmit results of search including list^, of candi- 
dates (if any) v 

Transmit search statistics (parameters) to SSAT< 

Receive authorization for updates or additions to 
Minutuae Master File (MMF) 

b. SPMs 

Receive data required to perform technical (finger- 
print) search 

Send search results to TSS 

c. Response by System Supervisor 

Send full HCIC fingerprint classifications (plus 
references) and subject data 

Receive search results 

Send search results 

Update MTR 

Form Image Comparison Request 
Send search statistics to SEAR 

Send authorization for updates or vsdditions to MMF 
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c. transaction piles 

(1 ) MTR (Matter Trant action Record) 


The daCe record concaina tracking data on each fingerprint card 
and ita related micro film image aa it flowa through the AIDS III 
Syatem. Tlie record ia maintained by proceaa control number (PCN) in a 
file aaeoeiated with the Syatem Superviaor. The basic activity 
against the record ia that, whenever a fingerprint card (identified by 
a PCN) is processed by a function with a computer interface, notifi- 
cation of that fact is transmitted to the MTR* This audit trail is 
effective in identifying cards in the syatem over a specified length 
of time and by the laat automated function in which the card had been 
processed. Sixty-four bits of storage are proposed. Other data 
contained in the MTR includes: card type and priority, identification 
statu8t> card disposition, and file maintenance status. 


(2) TR (Transaction Record) 


Although not fully defined, the TR is used to contain subject 
and arrest information that is stored temporarily (i.e. , the informa- 
tion that will ultimately be used for updating an existing record or 
creating a new record on the Criminal Name and Criminal Record 
files). Various steps through the process add data to the Transaction 
Record. Both the technical and subject searches use the information 
contained in the IR. Information contained in the TR includes PCN, 
microfilm location, microfiche location, subject search information, 
arrest and any additional information, NCIO fingerprint classification 
and references, and the FBI number. 
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APPENDIX H 


STUDY RESULTS OP APRS AND PCN AVAILABILITY 


A. AUTOHATIC PINGERPRINT READER SYSTEM (APRS) 

An analysii of PBI maintenance logi for the Automatic Finger** 
print Reader Syatem (APRS) currently being used in the fingerprint 
card file conversion and the Automated Technical Search Pilot Study 
was made. The basis for this analysis was the Technical Maintenance 
Unit Processing Section System (maintenance) Logs for all five AFRSs 
for the period June 1979 through December 1979. These logs covered 
unplanned maintenance (operation code 72), a few planned maintenance 
records (operation code 71), repairs, operation/service codes, 
assembly involved, and a description of the problem and correction. 
Table H“1 reflects the results of the analysis of the unplanned 
maintenance of the five AFRSs. (Preventive maintenance data is not 
included in the table). 


Table H-1. APRS Availability Including Processors 


System 

Number 

Maintenance 
Period 
In Weeks 

Service 

Number 

Repairs 

MTTR 
In Hours 
(Note 1) 

Response 
Time 
In Hours 
(Note 2) 

MTBF 
In Hours 
(Note 3) 

Unit 

Availability 
(Note 4) 

1 

27 

26 

0.61 

1.0 

140.2 

0.9886 

2 

21 

31 

0,84 

1.0 

91.5 

0.9803 

3 

25 

45 

1 .74 

1.0 

75.0 

0.9648 

4 

25 

31 

0.72 

1.0 

108.9 

0.9845 

5 

22 

25 

1.07 

1.0 

118.8 

0.9829 

Average 



1.00 

1.0 

106.9 

0.9816 

Notes: 

1. 

Mean Time to Repair 
excluding travel. 

- actual 1 

service time 

in hours. 



2. Period of time from machine failure to start of repair work (based 
on Rockwell response time estimates as stated in Reference 5). 

3. Mean Time Between Failures ^ 135 hr/week x Maintenance Period 

Number of Service Repairs 


4 


Unit availabiUty ^ MTBF 

MTTR V' Rfl ipohaa " Tiine ” + MTBF 


The availability for the ARFRs (including proceaeore) derived in 
Table H-l is 0«9886t which is somewhat better than tiie availability of 

0.9500 indicated by Rockwell in Reference 24f page 6. 

The following is a tabulation of the maintenance information for 
the AFRSs excluding the processors. 


Table H-2. APRS Availability Not Including Processor 


Systemi 

Number 

Maintenance 
Period 
In Weeks 

Service 

Number 

Repairs 

MTTR 
In Hours 
(Note 1) 

Response 

Time 

In Hours 
(Note 2) 

MTBF 
In Hours 
(Note 3) 

Unit 

Availability 
(Note 4) 

1 

27 

19 

0.76 

1.0 

191.84 

0.9909 

2 

21 

22 

0.74 

1.0 

128.86 

0.9867 

3 

25 

37 

1.21 

1 .0 

91.22 

0.9763 

4 

25 

28 

0.76 

1.0 

120,54 

0.9856 

5 

22 

17 

0,78 

1.0 

174.71 

0.9899 

Average 



0.85 

1.0 

141,43 

0.9883 


Notes: 

1. Mean-Time-to-Repair « total service time in hours, 
excluding travel. 


2. Period of time from machine failure to start of repair 
work. 


3 


Mean-Time~Be tween-Fai lur e 8 


135 hr/week x Maintenance Period 
Number of Service Repairs 



Unit availability 


MTBF 

MTTR + Response Time + MTBF 
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t«ble H-2 gives an overall MTBF of 141. A3 hours i which is 
considerably less than Rockwell's 700 hours (Reference 24» page 6). 

The FBI log MTTR (0.85 hours), plus the Rockwell estiisated responBe 
tisiB (1,0 hr' equals 1.85 hours which is shorter than Rockwell's 
estimated 4.0 hours (3.0 hours, given in Reference 24, page 6, plus 
the estimated 1-hour response time from Reference 5, page 47), 

The empirical JPL deta was used in the development of the 
simulation model. It was felt that this data reflected a more realis- 
tic view of actual conditions. A concern of AFRS availablility is the 
potential decreasing MTBFs and increasing KTTRs as the equipment 
ages. No experience was presented which would assist in this projec- 
tion. 


B. PROCESS CONTROL NUMBER (PCN) MACHINES 

An analysis of FBI maintenance logs was made for the period 
September 1978 through April 1979. Table H-3 reflects the results of 
this analysis. The average MTBF for the PCN machines during this 
period was 126.14 hours. This compares to 168 hours stated by Rock- 
well (Reference 24, page 6). The average Mean-Time-To-Restore from 
the FBI log is 3.39 hours as compared to the Rockwell Mean-Time- 
To-Restore of 1.6 hours plus (a repair time of 0.6 hours, and an 
estimated 1 hour- response time). 

Using the Rockwell numbers, the average availability for the PCN 
machines was 0.9906 whereas based on JPL study information, the 
average was 0.9738. This difference did not seem to have a signifi- 
cant effect on the system availability unless a prolonged failure 
occurred. This component had the lowest availability factor and, if 
the two machines proved to be unrelieble, a significant queue could 
build up at this point. 

The empirical JPL data was used in the development of the 
simulation model. It was felt that this data reflected a more realis- 
tic view of actual conditions. A concern of PCN availability was the 
potential decreasing MTBFs and increasing MTTRs as the equipment 
ages. No experience was presented which would assist in this projec- 
tion. 
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Table H-3 PCN Printer Availability 


PCN Systems 

Mean-Time 
To-Repair 
In Honrs 
(Note 1) 

Responae Time 
In Hours 
(Note 2) 

MTBF In Hours 
(Note 3) 

Availability 
(Note 4) 

1 

3.70 

1.0 

158.82 

0.9713 

2 

1.08 

1.0 

93.46 

0.9782 

Average 

2.39 

1.0 

126,14 

0.9738 


No tea t 


1 . 

2 . 

3. 

4, 


Total-Service-Time in Hours, excluding travel. 

Period of time from machine failure to start of repair work. 

« m!-. _ 135 hr/week x Maintenance Period 

M..i.-Iime-Bet«Mn-F.ilure. NiaefoTservice Rep.it. 

• * wtbf 

Unit availabxlity ■ Repair Time + Reaponse Tin>e + MTBF 
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APPENDIX I 


discrepancies between work load values 


Figure I-l showR the Design Work Loads for the AIDS III 
processing functions in which the work flow is measured in cards/day. 
In Figure 2, all figures have been converted to cards/hour during the 
day shift, using the formula: 


2 1 

cards/hour (day shift) e — x yj cards/day 

to provide for the 2:1 ratio of the day shift over the night shift. 

The Rockwell AIDS III Operating Concept Chart displays a vi.ew of 
the system in terms of cards/hour, based upon the Design work loads in 
Figures I-l and 1-2, Using the work load information provided in the 
Operating Concept Chart, Figure 1-3 was drawn. It was found that 
there are certain discrepancies between the two sets of numberSA 

In order to analyze the meaning of these discrepancies, Table 
I-l was created. It lists the percentage values at which the workflow 
splits at selected nodes in the system. These nodes correspond to 
nodes used for the computer simulation studies that were conducted for 
the AIDS III Evaluation Report. The model is shown in Figures 4 and 
5, where the selected nodes are identified as NODE 1, NCDE 2 and NODE 
3. Tl»e Table also includes information on other percentage values of 
special significance. 

The two percentage numbers given for each item in the Table 
correspond to values calculated according to the information provided 
in the Design Guidelines of the Identification Division of the FBI and 
the Operating Concept Chart of Rockwell, respectively. 

The disagreements between the two sets of numbers can be seen by 
observing Figures 1-2 and 1-3. Most of the differences are small and 
probably of little significance, except for the fact that they do 
exist. After examining Figures 1-2 and 1-3 and Table 1-1, a few 
observations can be made: 

(1) In the Design Guidelines, 32% of the total number of cards 
that go to Subject Search (SS) are criminal cards, 
compared to 49.56% in the Operating Concept Chart 
(Table I-l). 
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Figure I*-l. Design Guidelines Work Loads - Cards/Day 
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Figure 1-2. Design Guidelines Work Loadjs - Cards/Hour (Day Shift) 








2594 






535(.> 


ASSUMING A FUT3K63?o 
FALSE DROP RATE 


Figure 1-3. Operating Concept Chart Work Loads - Cards/Hour (Day Shift) 








(2) The percentage of cards with FBI numbers (both as a 
fraction of the total number of cards, and as a fraction 
of the total number of criminal cards) is significantly 
higher in the Operating Concept Chart (11 #44% against 18% 
and 22% against 35.54%, respectively). This differential 
should result in a higher success rate by the Subject 
Search function, with off-loading of the Technical Search 
Function as a consequence. This is confirmed by the 
percentages of cards with unverified SS candidates of 
35.08% (FBI) against 42% (Rockwell). However, the total 
number of cards idented by the system is equal in both 
cases (37%), and the percentage of Criminal Cards with 
verified SS candidates is 59.49% (FBI) against 47.87% 
(Rockwell), which seems contradictory. The most likely 
reason for the apparent contradiction is that the Design 
Guidelines contain information only on verified idents. 

On the other hand, the Operating Concept Chart shows 
information on unverified identS, and gives an overall 
false drop rate after the Image Comparison (Verification) 
function has been completed. This makes comparison 
between figures in both charts difficult. The figure of 
47.87% was calculated using the 31.63% false drop rate as 
the Table indicates which, in this case, was probably not 
a very accurate approximation. The false drop rate will 
vary depending on the card type even though, overall, it 
will stay approximately at the 31.63% level. 

(3) From Table I-l, the percentage of cards with verified 
Technical Search idents and no SS candidates is 5.74% 
(FBI) against 19.49% (Rockwell). However, the figure of 
19.49% was calculated using the alreadymentioned false 
drop rate of 31.63%, which might not be accurate for this 
card type . 


In the Rockwell chart, an alternative to calculating the 
number of TS idents is to apply the TS success rates for 
civil and criminal cards as deduced from the Design 
Guidelines. Using Figure I-l: 


The probability of finding TS candidates for civil 
cards, given that no candidates were found in SS: 


58 

9538-1568' 


X 100 =0.7% 


The probability of finding TS candidates for 
criminal cards, given that no candidates were found 
in SS: 



625 

5609-1679 


X 100 = 15.9% 
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TABLE 1-1 



Identification 

Rockwell 


Division Design 

Operating Concept 


Guidelines 

Chart 

NODE 1 



Full Classification (Civil & Military) 

47.99% 

50% 

Blucking-dut (Criminal w/o FBI #) 

40.57% 

32% 

With FBI # 

11.44% 

18% 

NODE 2 



Criminal w/o Candidates 

21 .08% 

15% 

Civil w/o Candidates 

35.85% 

38% 

Cards with SS Candidates (unverified) 

35.05% 

42% 

Military w/o Candidates 

7.99% 

6% 

NODE 3 



To CSORT 

44.72% 

43.4% 

To Civil File 

7.99% 

5.4% 

To MFPHOLD 

35.10% 

39.4% 

To AUTOCOT 

12.20% 

11.8% 

MISCELLANEOUS 



% of CriminaY Cards with FBI # 

22% 

35.54% 

% of total n<^ of Cards idented 
% of Cards wira TS idents (verified) 

37.66% 

37.4% 

given they l^d no SS Candidates 
% of Cards with\TS idents (unverified) 

5.74% 

19.46% * 

given they hacJ no SS Candidates 
% of Civil Cards Vith SS Candidates 

N.A. 

28.46% 

(verified) \ 

% of Civil Cards wrth SS Candidates 

8.66% 

10.64% * 

(unverified) 

N.A. 

15.56% 

% of Criminal Cards with SS Candidates 
(verified) . 

% of Criminal Cards with SS Candidates 

59.49% 

47.87% * 

(unverified) 

N.A. 

70% 

% of Criminal Cards in the mix of civil 


and Criminal Cards that go to Subject 


Search 

52% 

49.56% 


^Assuming a false drop rate of 31.63% 
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Figure 4. Work Cell Model 





























Applying these results to the Operating Concept Charts 
(1) Civil cards! 

Of the 852 cards/hour without $S candidatesi 15% (see 
Rockwell Technical Memo 080-010, pngc 3, item #5) are 
illegible. 


( 2 ) 


852 - 852 X • 716 cards/hour 
.1% of 716 * 5 civil cards/hciir idented in TS (verified). 
Criminal Cards: 


Of the 335 cards without SS candidates, 50% (sen Rockwell 
Technical Memo 080-010, page 5, item #5) are illegible. 

335 - 335 X ^ » 234 cards/hour 

15% of 234 • 35 criminal cards/hour idented in TS 
(verified) 

The total number of cards idented and verified in TS (with no SS 
candidates) according to the success rates deduced from the Design 
Guideline is 35 5 " 40 cards/hour. 

In Figure 1-6 we a&e that, according to the Operating Concept 
Chart, there are 294 cards/hour for which TS has found (but not 
verified) candidates. 


Combining both results: 


294-40 

294 


X 100 « 


862 false drop rate in TSI 


This surprising result shows, again, an inconsistency between 
the work load values under consideration as they appear in both charts. 


We find in Table 1-1 that the percentage of cards with 
(unverified) 

TS idents and no SS candidates is 28.46%. This is much too high, 
confirming the inconsistency of some figures in both charts. 


Work Loads Used in the Simulation Model: 

The work load information provided in the Identification Division 
Guidelines is not enough to create an Aids III model that can be used 
in the simulation. The Rockwell Operating Concept Chart contains a 
study of AIDS III work loads that is more comprehensive. It contains 
additional information that was obtained from outside sources and 
direct measurements, and is a consistent set of numbers in itself. 


Q 
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For these reasons, the work loads in the computer model utilized 
for the simulation studies were either taken directly from the 
Rockwell Operating Concept Chart or were derived from it. 

By way of reference, a listing of the calculations made to 
create Table I*“l is given below. 

A. PRE-SEARCH (NODE 1): 

1. Design Guidelines: 

Input to node: 13840 + 12769 ■ 26609 Cards 

(a) Full Classification (Civil & Military Cards); 

^ X 100 . 47.991 

(b) Blocking Out (Criminal Cards w/o FBI number): 

'26609 ^ " 40.57% 

(c) Criminal Cards with FBI number: 

^ X 100 - 11.44* 


2. Operating Concept Chart: 

(a) All values are taken directly from the Chart. 

B, SUBJECT SEARCH (NODE 2): 

1. Design Guidelines: 

(a) Criminal Cards w/o SS Candidates: 

mi X 100 . 21.08* 

(b) Civil Cards w/o SS Candidates: 

mi - - 35.85* 


I-ll 


(c) Military Cards w/o S$ candidatsii 

wo-7,m 

(d) Cards with SS candidates (unverified): 

This information is not available in the Design 
Guidelines chart. Inasmuch as the sum of all four 
branches of this node must be 100, the percentage 
for this branch is: 

100 - (21.06 + 35,85 + 7.99) - 35.08% 


2. Operating Concept Chart: 

(a) All values are taken directly from the chart. 

C. POST-SEARCH (NODE 3): 

1. Design Guidelines: 

(a) To CSORT (Subject Search Non-Indents) 

(9538 + 5609 - 1568 - 1679) • 11900 

100 - 44.72* 

(b) To Civil File (Military Non-Ident) 

25si * 

(c) To HFPHOID (Subject Search Idents): 

3045 + 5118 + 1106 - 9339 

X 100 - 35.10% 

(d) To AUTOCOR (Illegibles): 

1568+1679 


26609 


X 100 «« 12 .20% 
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Zt Operating Concept Chart: 

Input to Node: A feedback loop aenda a total of 
60 68 128 carda back to Technical Search fron SEAR. In the Cell 

Model, thla feedback loop (point B in Segment 1 of Figure 5) reentera 
at the cell input. The ayatem that ia being modeled includea the cell 
concept; thua, the input to NODE 3 that ia uaed for the calculationa 
ia: 


2254 * 128 X 2382 carda/hr. 

(a) To CSORT (Subject Search Non-Identa); 

mi X 100 - 43,4% 

(b) To Civil File (Military Non~Ident): 

X 100 X 5,4% 

(identa); 

X 100 X 39.4X 
(lllegibles) : 

X 100 - 11.8% 


128 

2382 

(c) To MFPHOLD 

939 

2382 

(d) To AUTOCOR 

282 

2382 


D. 


MISCELLANEOUS: 

1. Design Guidelines: 

(a) % of Criminal Cards vith FBI number: 


3045 

13840 


X 100 


22 % 


(b) % of total number of Cards idented: 


3045-»-5188-H106»625»58 

13840+12769 


X 100 - 37.66% 


(c) % of Cards with TS idents (verified) given they had 

no SS Candidates: 


625+58 

9538+5609-1568-1679 


X 100 


5.74% 
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(d) % of C«rda with TS idents (unvei*£fi«d) given they 
had no SS Candidates: 

The Design Guidelines do not include the Image 
Comparison (verification) Function with the False 
drop rates. 

(e) X of Civil Cards with Subject Search Candidates 
(verified) : 

X loo - 8.66I: 

(f) X of Civil Cards with SS Candidates (unverified): 

All figures in the Design Guidelines are for 
verified idents only. Unverified idents do not 
appear in the work load chart. 

(g) X of Criminal Cards with SS candidates (verified): 

(h) X of Criminal Cards w it h SS Candidates (unverified): 
Not available from the chart. 

(i) X of Criminal Cards in the mix of Civil and Criminal 
Cards that go to Subject Search: 


U3^ :tlB - 52% 

2. Operating Concept Chart: 

The Operating Concept Chart contains information about the 
false drop rates in the form of a uniform ratio in the mix of Civil 
and Criminal Cards for which Subject Search or Technical Search has 
found potential candidates. From the information in the Chart, the 
percentage of the card mix verified as idents in Image Comparison is: 

X 100 • 68.37% 


This result has been used in the Table to calculate the 
percentages of verified idents for the Operating Concept Chart column 
for both Civil and Criminal Cards with Candidates from the searches. 

(a) % of Criminal Cards with FBI number: 

397+7M * 


i 
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(b) 


(c) 


(d) 


(e) 


(f) 


(g) 


(h) 


X of total number of Cards idented; 
843 


2254 


X 100 - 37.4% 


X of Cards with TS idents (verified) given they had 
no SS Candidates. In Figure 6: 

1233 “ 939 “ 294 Cards with Candidates (unverified) 

68,37% of 294 - 201 

201 


1033 


X 100 » 19.46% 


% of Cards with TS idents (unverified) given they 
had no SS candidates; 


From Figure S; 


a 1233 - 939 - 294 
294 


1033 


» 28 .46% 


% of Civil Cards with Subject Search Candidates 
(verified): 

Civil cards with SS Candidates; 

1137 - 128 - 852 - 157 

113f-128 * " 15.56% (unverified) 

68.37% of 15.56 « 10./64% 

% of Civil Cards with SS Candidates (unverified): 
From above: 15.56% 

% of Criminal Cards with SS Candidates (verified) : 
Criminal Cards wtih SS Candidates: 

397 + 720 - 335 » 782 

' 39/^720 * (unverified) 

68.37% of 70 - 47.87% ca 

% of Criminal Cards with SS Candidates (unverified): 
From above: 70% 
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(i) % of Criminal Cards in the mix of Civil and Criminal | 

Cards that go to Subject Search. | 
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ACS 

APRS 

AHU 

AIDS 

ANS 

AT’S 

ATSPS 

AUTQCOR 

AUTORESP 

A&R 

BER 

BLO 

GCA' 

CGH 

GGN 

GCNR 

GGR 

GT.R 

CLASS-A 

CLASS-B 

GLARR-C 

GLCK 

CNR 

GOA 

GPIT 


ACRONYMS 

Automated Glassification System 
Automated Fingerptint Reader System 
Anti“HaXation Underlayer 
Automated Identification Division System 
Automated Name Search 

Automated Technical Search » 

Automated Technical Search Pilot System 
Automated Correspondence Station (part of AIDS) 

Automated Response Generation (part of AIDS) 

Automation and Research Section of Identification Division 
Bit Error Rates 
Blocking Out 

Computerize'’ Contributor Abbreviated Name 
Computerized Criminal History (part of NCIC) 

Computerized Criminal Name 

Computerized Criminal Name and Record (part of AIDS) 

I'Joropufeerized Criminal (Arrest) Record (part of AIDS) 

Computerized Ident Response File (part of AIDS) 

Classification'-A 

Classif icati on-B 

Glass ification-G 

Glassification Check 

Computerized Non-Ident Response File 

Cutoff Age 

Central Processing Unit 
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CRS 

CRT 

CSORT 

DATE STR 

DBMS 

DF.DS 

DENT 

DENT-A 

DENT’-B 

DOA 

DOB 

ECL 

EMI 

ENO 

ENCDOC 

ENGK 

ENDOCK 

ERR 

EYE 

FBI 

FEP 

FIFO 

FEAB 

FLOAD 

FPC 

FPCS 

f/p 


Computerized Record Sent File (part of AIDS) 

Cathode Ray Tube 
Centerline Sort 
Date Stamp, Count and Log 
Data Base Management System 

Data Entry and Display Subsystem (part of AIDS III) 

Data Entry 
Data Entry-Cards 
Data Entry-Documents 
Date of Arrest (on f/p card) 

Date of Birth (on f/p card) 

Emitter Coupled Logic 
Electroffiagnetic Interference 
Encode Input Data-Cards 
Encode Input Data-Documents 
Encode Check-Cards 
Encode Check-Documents 
Update Error File 
Color of Eyes (on f/p card) 

Federal Bureau of Investigation 
Front End Processor 
First-In-First-Out 
Film Lab Prncessing/Computer 
Film Load 

Fingerprint Classification 

Fingerprint Correspondence Section of the Identification 
Division 

Fingerprint 


GDBMS 

GEO 

GPSS 

HAI 

HGT 

IBM 

ICI 

ICRQ 

ICS 

ICV 

ID, I.D. 
IDENT 
JPL 
KIPS 

LEAA 

mail 

MFIU! 

MIPS 

MMF 

MOE 

MTBF 

MTR 

MTTR 

NAM 

NASA 

NCIC 


General Purpose Data Base Management System 
Geographic Location (on f/p card) 

General Purpose Simulation System 
Color of Hair (on f/p card) 

Height (on f/p card) 

International Business Machines Corporation 
Image Comparison Identification 
Image Comparison Request 

Image Comparison Subsystem (part of AIDS III, actually 
used for iriage retrieval for manual comparison) 

Image Comparison Verification 

Identification Division 

Identification 

Jet Propulsion Laboratory 

Thousands of Instructions per Second (as executed by a 
computer) 

Law Enforcement Assistance Agency 
Open Mail and Sort 
Image Capture Microfilm 

Millions of Instructions per Second (as executed by a 
c amp u ter) 

Minutiae Master File 
Measures of Effectiveness 
Mean Time Between Failures 
Master Transaction Record 
Mean Time to Restore 
Name (on f/p card) 

National Aeronautics and Space Administration 
National Crime Information Center 
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NCR 

OCA 

OCR 

OHB 

ORI 

PCM 

PICS 

PMT 

POB 

QG 

QUERY 

RAC 

READ 

RFI 

RH 

RVF 

SACS 

SAR 

SEAR 

SEX 

SID 

SKN 

SOC 

SPM 

SS 

SSM 

SSRG 


National Gash Register Company 

Local Identification Number (on f/p card) 

Optical Character Recognition 
Office of Management and Budget 

Originating Agency Identification Number (on f/p card) 
Process Control Number 

PCN and Image Capture Subsystem (part of AIDS III) 

Photomultiplier Tubes 

Place of Birth (on f/p card) 

Quality Control 
On-Line Query 
Race (on f/p card) 

Quality Control Check, Read, Annotate 
Radio Frequency Interference 
Relative Humidity 
Ridge Valley Filter 
Semi-Automatic Classification System 
Semi-Automatic Fingerprint Reader 
Search Review 

Reported Sex of a Subject (on f/p card) 

State Identification Number 
Skin Tone (on f/p card) 

Social Security Number (on f/p card) 

Search Processor Module 

System Supervisor Subsystem (part of AIDS III) 

Subject Search Module 

Subject Search and Response Generation Subsystem (part of 
AIDS III) 
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TDFA 


TFO 

TR 

TRC 

TSS 

TTL 


VDENT-A 

VDENT-B 

VT,SI 


Top Down Functional Analysis 
Technical File Conversion 
Transaction Record 
Transaction Control File 

Technical Search Subsystem (part of AIDS III) 

Transistor - Transistor Logic 

Verify Data Entry-Cards 

Verify Data Entry^Documents 

Very Large Scale Integration 

Wand Out of System 


WAND 


